Home
Note that this FAQ is "work in progress". There are many questions and answers to those still not listed here. Just has not been enough spare time to add them yet. If you feel that a question is not answered here or anywhere else on the Wiki, please report it to the issue tracking system.
A: Currently rar2fs has been verified to work on Linux (for which it was originally written), FreeBSD 7 and Mac OS X based platforms using the GNU C/C++ compiler. Later versions also includes a port for OpenSolaris (snv_126 baseline) and Windows using the WinFSP/cygfuse layer or Dokany. Both glibc and uClibc distributions have been tested on a number of different architectures. The design of rar2fs has attempted to be as portable as possible. Still there might be several target platforms for which it does not work when it in fact should. In those cases please report it to the issue tracking system. In theory rar2fs should be possible to run on any platform with FUSE support and POSIX threads.
A: There is now. The GNU Autotools suit is supported starting from version 1.13.7. The earlier build systems is still available though. To use that edit config.mk and do 'make -f Makefile.mk'. However, future support will be limited and there is no telling when it will be removed completely or even break before that happens.
A: It depends. The rar2fs package can be officially downloaded in two different ways. As a released distribution in the form of a compressed tar-ball or by using the latest version cloned from the git repository itself. The build procedure is similar but not identical. Using the earlier build system the procedure is the same, see question 1.2 above. For automake builds the released tar-ball is already prepared and a simple command sequence as seen below should do the trick (from the source tree root).
./configure && make && make install
If the latest version is checked out from the git some additional preparations are needed.
Grab the latest UnRAR source from here, find "UnRAR source" and extract it into the git clone of rar2fs.
Neatly packed instructions for the (at time of writing) latest UnRAR source version and rar2fs.
git clone https://github.com/hasse69/rar2fs.git
cd rar2fs
wget http://www.rarlab.com/rar/unrarsrc-5.4.5.tar.gz
tar -zxvf unrarsrc-5.4.5.tar.gz
Compile the library from the relative path of the git clone and install it.
cd unrar
make lib
sudo make install-lib
cd ..
Following compilation of the unrar libs, it's then easy to install if GNU autoconf/autoheader/automake tools are all setup properly and of compatible version.
autoreconf -f -i
./configure && make
sudo make install
A: It is experimental, very experimental. It was an attempt some time back to add a few glibc GNU extensions that many uClibc distributions tend to leave out, such as function fmemopen(). For now, just forget about it, it simply does not work as intended. It is left there in the unlikely case that it will be picked up again sometime in the future.
A: The unrar source tree is needed because rar2fs is adding some features on top of the libunrar API and by doing so also inherits some code from it out of convenience. These extensions are completely built into rar2fs and does not directly affect libunrar itself. However, since rar2fs always targets on the latest unrar source version, it is most likely necessary (and seriously recommended) to also replace libunrar.so on the target system to match the source version being used.
A: Use the install target 'make install' from the Makefile generated by the configure script. You can read more about how to change installation path etc. in the INSTALL file. If your still on an old version of rar2fs without support for GNU Autotools you will have to install the necessary files manually. But that is not a big deal, after all, there are only three files of interest really; the rar2fs and mkr2i binaries and the rar2fs.1 man page.
Q 1.7. I get this error when compiling libunrar: relocation R_X86_64_32 can not be used when making a shared object; recompile with -fPIC
A: On some platforms, especially 64-bit versions, the compiler does not automatically produce shared libraries with placement independent code. Add the -fPIC option to the CXXFLAGS in makefile.unix to solve this error:
CXXFLAGS=-O2 -fPIC
Note that this change is only required in the libunrar makefile(s). You do not have to change anything in rar2fs.
A: There are many options that can be fed to the program. The complete set of options are described in the rar2fs man page. But in its simplest form rar2fs is invoked like:
rar2fs some_source_folder some_target_folder
The source folder (or root folder) is the path to the folder containing some or all of your RAR archives, and normal files/folders too for that matter. The target folder is your "mount point". It works very similar to a bind mount in that sense. When you bring up a folder listing of your target folder, any RAR archives will be hidden and instead the files/folders within the RAR archives are displayed as if they were normal files/folders on your file system.
From version 1.11.12 it is also possible to mount single RAR archives or volumes instead of a directory. Simply replace the source directory with the name of the archive file. For a RAR volume the file specified must be the first in the set, such as:
rar2fs some_archive.part01.rar some_target_folder
A: The design of rar2fs attempts to be robust. In this case rar2fs has detected that your system library path points out a version of libunrar.so that is not compatible with what rar2fs was built against. Try replacing libunrar.so or force loading of a different version using your LD_LIBRARY_PATH or LD_PRELOAD environment variables. As a last resort you can also try the --no-lib-check option in an attempt to ignore the potential incompatibility. If, for some reason, this option is chosen do not be surprised if cutting corners like that will cause undefined behavior or even crashes. Note that rar2fs can only detect an API version mismatch. Binary compatibility can never be guaranteed. Since building the libunrar API extensions require the full unrar source tree, it will in most cases break everything if libunrar.so is not also replaced on the target system.
A: This is a similar problem to what is described in question 2.2 for libunrar. This time it is the version of your systems FUSE library that rar2fs does not agree upon.
A: No. It can not. The RAR archives are internally treated as read only. The RAR compression algorithm (not excluding store mode) is proprietary and as such protected by a copyright license.
A: Yes and no. There are plans of adding that feature. Too early to say when it will be officially supported though. But some limited experimental write support was added to version 1.11.13. Feel free to try it out.
A: Yes, you can. But it is not recommended to change information behind the back of rar2fs like that. A lot of information about each file inside an archive is cached for faster lookup. Since rar2fs currently does not subscribe to file system events through eg. the inotify or dnotify interfaces there is no way for rar2fs to detect the change and invalidate the cache accordingly. Thus, depending on the change made, this could lead to unexpected behaviour. If you really need to change the contents of a RAR file on a live file system, make sure you reset the cache before attempting to access the archive. This can be achieved by sending a signal to the parent rar2fs process:
kill -USR1 <pid>
This will purge all entries in the cache. The cache will then have to be populated again from scratch which means you might initially experience some extra delay during display of archive contents.
A: There seems to be some fuse distributions/packages that are not correctly configured for user mounts, except from the root account. Most commonly this is because the ownership of the fuse device is not set properly. In those cases try to mount your rar2fs file system as root instead, and if needed, use the fuse options uid, gid and umask to assign the effective user/group of the calling process.
A: Yes, of course there is. The most common reason for slow folder display is that too many volume files are searched for header information. Using the option --seek-length should help in those cases. Also the --exclude option may prove useful. Check the rar2fs man page for details on how to use these two options. The default value of seek length has been set to obtain highest possible level of compatibility rather than speed.
Q 2.9. rar2fs is supposed to support RARs inside RARs, but my VobSub packages does not work properly. Why is that?
Check out the --seek-depth option. It will most likely be the answer to your question. The rar2fs man page will tell you more. Note that from version 1.14.0, seek depth will be set to the maximum supported value by default. From version 1.15.22 the option --seek-depth is obsolete and --seek-depth=0 is replaced by --flat-only. Note that from version 1.24.0 this option and the built-in support for multi level archives has been completely removed. To expand multi-level archives stacking should be used instead.
musl-libc has a lower thread stack size by default than glibc, 80K vs 2M. This is causing fuse to crash.
The stack size for fuse processes can be changed using the following environment variable FUSE_THREAD_STACK.
e.g.
// set FUSE_THREAD_STACK to 160K instead of using the musl default of 80K
export FUSE_THREAD_STACK=160000
A: To automatically mount using systemd you need to edit/create the .automount and .mount unit files.
Example setup:
- Mount point with .rar archives in it: /mnt/mymount/rarfiles
- Mount point where rar2fs will serve the magic: /mnt/mymount/magic
Before you begin, ensure you are able to manually mount the filesystem using the mount command not using rar2fs directly. This will ensure that you have the proper fileystem type to specify in the unit file, and also that the system can find the mount.rar2fs binary.
On my raspberry pi OS install, mount.rar2fs was installed in /usr/local/sbin, so I needed to add a symlink in /sbin
sudo ln -s /usr/local/sbin/mount.rar2fs /sbin/mount.rar2fs
systemd requires that the unit files has the same name as the "where" path but with "-" instead of "/" to reflect the file system path.
Create the two files like below, change the name of the file to your desired path. Then copy the contents and change the path once more and add any additional options that you want to pass to rar2fs for mounting.
- mnt-mymount-magic.automount
[Unit]
Description=Automount magic
[Automount]
Where=/mnt/mymount/magic
[Install]
WantedBy=multi-user.target
- mnt-mymount-magic.mount
[Unit]
Description=Show me some rar2fs magic
[Mount]
What=/mnt/mymount/rarfiles
Where=/mnt/mymount/magic
Type=rar2fs
Options=allow_other
[Install]
WantedBy=multi-user.target
The Type= specification was originally Type=fuse.rar2fs but that was failing on a debian host since it was not able to find the mount.rar2fs file when the type was fuse.rar2fs
It is also possible to pass rar2fs flags in the Options field. For example if wanted to pass --seek-length=1 in the example above, it would look like this
Options=allow_other,--seek-length=1
If we did everything correct above we should now be able to copy and enable the unit files:
# Copy files to systemd
cp mnt-mymount-magic.* /etc/systemd/system/
# Reload systemd before trying to start them
systemctl daemon-reload
We should now try to start the .automount unit to see that it's functioning correctly:
systemctl start mnt-mymount-magic.automount
systemctl status mnt-mymount-magic.automount
● mnt-mymount-magic.automount - Automount magic
Loaded: loaded (/etc/systemd/system/mnt-mymount-magic.automount; disabled; vendor preset: disabled)
Active: active (waiting) since Wed 2017-03-08 18:38:50 CET; 31min ago
Where: /mnt/mymount/magic
mar 08 18:38:50 hostname systemd[1]: Set up automount Automount magic.
And for the last part we'll enable the service and verify that it mounts:
# Enable the systemd unit
systemctl enable mnt-mymount-magic.automount
# List contents in magic (if you have any .rar files in /mnt/mymount/rarfiles already)
ls /mnt/mymount/magic
# Now let's check that the mount was successfull
systemctl status mnt-mymount-magic.mount
# You should get something like this from the status command if all went OK
mar 08 18:21:00 hostname systemd[1]: Mounting Automount magic...
mar 08 18:21:00 hostname rar2fs[15002]: mounted /mnt/mymount/magic
Links
External Links
RARLAB Home
FUSE Home
AVI-Mux GUI Home
MacFUSE Home
Fuse4x Home
OSXFUSE Home
Mailing List Archives on Nabble
WinFSP
Cygwin