2 FAQ
I see a new /dev/fuseN device
is created upon each mount of a Fuse based filesytstem. What can I
do with those which are not in use anymore?
You can reuse them. If you do
mount_fusefs /dev/fuse0 /mnt/fuse foofs
or
FUSE_DEV_NAME=/dev/fuse0 foofs /mnt/fuse
instead of
mount_fusefs auto /mnt/fuse foofs
or
foofs /mnt/fuse
you will guaranteedly use /dev/fuse0 (or be refused if
it’s already in use).
But I’d rather clean them away…
Feel free to delete them. It won’t really make resources free – the they are just access points from the userspace to the device, the device itself remains inact. You can later re-create the devfs entry, with, eg.
mknod /dev/fuse0 c 0 0
There is no specific reason for keeping the devices themselves around. This is how the kernel likes to organize resources. Trust your kernel.
If you really want get rid of the unused devices, unload the fuse module and load it again.
The filesystem daemon has died for some reason. Can I start a new copy of it as a drop-in replacement?
No. The filesystem hierarchy is stored in the daemon process’ memory and it’s neither serialized nor appears on a permanent storage. If the daemon dies, the filesystem goes away. No use of keeping it around.
But what if I use a daemon which is “displaying” a stateless filesystem or organizes serialization and permanent storage by itself?
Well, if really that’s the case, the daemon should fork a “gatekeeper co-daemon” which keeps the fuse device open and spawns the new daemons on demand. As long as the device is open, the filesystem won’t be considered as “doomed”.
Bug the authors of permanency-capable filesystems if you have such needs or implement it by yourself.
What filesystems? As far as I know,
sshfs
is the only useable Fuse based “real” filesystem under
FreeBSD…
This is just the humble present. Other filesystems should be easy to port to FreeBSD (just a matter of a compilation with proper flags and includes). If a binding for an interpreted languages gets ported, probably a whole bunch of filesystems will be available immediately.
Feel free to contribute. See also
http://fuse.sourceforge.net/wiki/index.php/FileSystemsOnFreeBSD.
The daemon has died. Now I can’t get
rid of the Fuse mount: when I try to unmount the filesystem, the umount
command hangs.
Try unmounting by device name. That is, if you mounted the filesystem as
mount_fusefs /dev/fuse0 /mnt/fuse foofs
then do
umount /dev/fuse0
(instead of umount /mnt/fuse) – this works
without asking for assistence from the daemon. If you refused with
Device busy, then try a forced unmount (add the -f
flag). If unmount still hangs, that means that there is a process which
is using the filesystem and is also hanging. Search & destroy such
processes and try again.
But do I not need to fear of a forced unmount? Won’t my system panic upon doing so?
It definitely should not. However, if it still does, that’s a
bug. Please drop then a mail to the
fuse4bsd-devel
mailing list with the appropriate description of the case.
How can I find out the name of the Fuse device used by my filesystem and the pid of the daemon?
If you mount with an explicit device name like
mount_fusefs /dev/fuse0 /mnt/fuse foofs
then of course you will know the device name (although your mount attempt
will be refused if /dev/fuse0 is already in use).
In case of “auto” mounts you’ll be informed about
the device if you mount with -v like:
mount_fusefs -v auto /mnt/fuse foofs
or
MOUNT_FUSEFS_VERBOSE=1 foofs /mnt/fuse
When the mount is in place, the
mount(8)
utility will give you information how devices correspond to mount paths.
If you know the device of your mount, do an
fstat /dev/fuse*
to see the users of the fuse devices. See also
fstat(1).
Now the contrary. I unmounted a Fuse based
filesystem, and the umount has completed cleanly. However, the daemon
is still kicking and is occupying the respective Fuse device, and I
have to kill -9 it.
You either use an old version of the Fuse library / fuse4bsd or the filesytem in question doesn’t make use of the respective standard library routine.
Try upgrading to Fuse >= 2.5.0-pre2 and fuse4bsd >= 0.3.0-pre1.
Yet another weirdness upon unmount. The daemon
did exit, but uhh… It wasn’t a nice death. It dumped core
or displayed a strange message like Thread 8090600 has exited with leftover thread-specific data after 4 destructor iterations…
You use an old version of the Fuse library. Try upgrading to Fuse >= 2.5.0-pre2.
So what is this hype about Fuse and non-privileged mounts?
Fuse is designed so that anyone can use it without risking the consistency of the system. That is, a Fuse daemon process is not needed to be trusted. Whatever the daemon is doing, no worse outcome should this have (beyond the daemon’s privileges) than a non-functional mount.
How can I enable non-privileged mounts?
Use the standard FreeBSD toolset for this purpose. That is, set the
vfs.usermount sysctl to 1. Then find out
whom should be able to mount Fuse based filesystems and set the
devfs(8)
rules for /dev/fuse* appropriately. Eg., letting all users
to mount Fuse devices would look like
devfs rule add path 'fuse*' mode 666
(of course, you can chmod/chown individual Fuse devices, too). According
to the default permissions, members of the operator group
are those who can use Fuse based filesystems.
Does this support of non-privileged mounts mean that I should let everyone mount Fuse filesystems?
No. Your mileage may vary. Noone will say you are a fool if you find non-privileged mounting inconsistent with your system policy. And regarding Fuse, there might be bugs in it, as in any software. Allowing a user to mount Fuse based filesystems will make those bugs exploitable for that user.
However, it looks not too much dangerous to allow non privileged mounting of Fuse filesystems.
I do want to make it possible for some users on my system to mount Fuse filesystems, yet I don’t want to allow them to mount without restrictions. Is there any way to achieve this?
Yes. Keep the vfs.usermount sysctl on 0,
and set the appropriate access policy on the usage of mount_fusefs
as root by
sudo(8).
Note that you should not put mount_fusefs into
your “sudoers” file as is, as that command is capable of
executing an arbitrary command. There are various ways of disabling
this feature. Eg., passing a -S flag to mount_fusefs
will cause it to reject spawning daemons, or specifying a certain daemon
(by an absolute pathname) will make it run that specific daemon and
nothing else.
In general, you are suggested to wrap mount_fusefs into
a script. The command line parsing routine of mount_fusefs
desinged so that it makes scripting easy.
I run mounted a Fuse daemon using my own unprivileged account, and now my wife is in tears because she is prohibited from using the filesystem (which works finely for me). What’s happening here?
If your wife used the filesystem, all her I/O activity directed at the filesystem would be seen and controlled by your daemon process. This shouldn’t happen without your wife’s agreement, so to stay on the safe side, she will be bluntly refused from using your filesystem.
The “agreement” above is not just a metaphor. She can effectively
“sign” such an agreement by doing a so-called secondary
mount of your filesytem. First she has to find out or be told
about device your filesystem is using, say it’s /dev/fuse0.
Then she can do the secondary mount like
mount_fusefs /dev/fuse0 /home/kate/lesliefs
From that on, she will be able to use the filesystem (either via her
private mount point or via the original) while the secondary mount
is in place. The secondary mount will appear with /dev/fuse0#1
as device name and it should be unmounted via device name like
umount /dev/fuse0#1
(umount /home/kate/lesliefs would be redirected to
the primary mount like any query on the secondary mount!)
I want to mount a Fuse daemon such that the
mount would be systemwide useable, but I want the daemon running on
a low privilege level (like as user nobody). Will then
all of my users have to do their own secondary mount before they can
use the filesystem?
Not necessarily. Just use the allow_other mount option
(available only for root).
