2 FAQ

I see a new /dev/fuseN device is created upon each mount of a Fuse based filesytstem. However, I’d like to see the existing one getting reused.

The development version supports device reusal. If you’d like to stay away from the bleeding edge, you can force reusing an existing device by explicitly specifying it, eg.

mount_fusefs /dev/fuse0 /mnt/fuse foofs

or

FUSE_DEV_NAME=/dev/fuse0 foofs /mnt/fuse

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 ruleset 10
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 set up Fuse based filesystems. (Ie., only they can do primary mounts. Others still can use an already mounted Fuse filesystem via secondary mounts, if the filesystem doesn’t prohibit this. See  2.)

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 in 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).