GNOME Bugzilla – Bug 607706
Nautilus can't properly unmount FUSE filesystems
Last modified: 2018-09-21 17:00:47 UTC
Normal users can create and mount fuser-filesystems, such as encfs and sshfs. By executing e.g. the command "encfs ~/somedir ~/some-other-dir", such filesystems correctly show up on the desktop as mounted filesystems. However, if you right-click and select "unmount" you get a error-message saying you cannot unmount the filesystem, because it does not appear in fstab, and you are not root. This is factually incorrect -- you *can* unmount the filesystem, assuming you're the user who mounted it in the first place, by using the command "fusermount -u directoryname" Nautilus should be able to properly unmount FUSE file systems. This bug was originally reported by Eivind Kjørstad on Launchpad in Ubuntu at <https://launchpad.net/bugs/254171> and later also by Brian M. Carlson in the Debian Bug Tracker at <http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=514453>.
I guess the fix is trivial. Pity noone is interested.
I can confirm this bug. It seems to be like this with all FUSE file systems in Nautilus. A guess would be that Nautilus internally uses umount by default, and so when a volume is mounted with fuse (which is becoming more and more popular these days, no need to mess around with root) it won't unmount both because "umount" doesn't know it's mounted, and because one does not have root privileges. It can be easily verified with the following commands: cd $HOME mkdir test1 test2 && echo "temppass" > tempfile encfs --standard --stdinpass $HOME/test1 $HOME/test2 < tempfile && rm tempfile Now try to unmount this volume ($HOME/test2) from Nautilus. It will present the same message as when umount is used to unmount: umount $HOME/test2 umount: /home/rune/test2 is not in the fstab (and you are not root) fusermount works without problems: fusermount -u $HOME/test2
I too can confirm this bug.
Could you please post your /proc/mounts?
Looking at the util-linux-2.19.0 changelog, mount support for subtypes has been added on several places. Let me test it here...
Created attachment 185749 [details] /proc/mounts Attaching /proc/mounts after mounting an encfs filesystem.
(In reply to comment #6) > Created an attachment (id=185749) [details] > /proc/mounts > > Attaching /proc/mounts after mounting an encfs filesystem. Thanks, this is sane on my system as well. I talked to Karel Zak, who pushed the mount support for subtypes in util-linux. There are two cases for user mounts: 1. with record in fstab: mount options must contain the "user=" argument to be able to umount from user side. 2. no record in fstab, mounted from user command: mount options must specify the "uhelper=" command which is called on umount. Both options are supposed to be added by the mount command (helper respectively), specifying them in fstab only results to error. Testing with util-linux-2.19-3.fc15 and fuse-2.8.5-5.fc16, none of these two cases work on my machine. This is probably something that needs to be fixed on fuse side.
(In reply to comment #7) > Testing with util-linux-2.19-3.fc15 and fuse-2.8.5-5.fc16, none of these two > cases work on my machine. This is probably something that needs to be fixed on > fuse side. Tomas, I am sorry, what's the big deal having a special code for FUSE fs'? Do you really think that would pollute the code?
*** Bug 560026 has been marked as a duplicate of this bug. ***
Gdu volume monitor has been superseded by udisks2 volume monitor long time ago. I am closing this bug because many have been changed since this was reported. If this is still an issue with the recent gvfs releases, please reopen and change component to udisks2 volume monitor.
Just a note that as per the quite recent comment from Karel Zak, you can use the following workaround: The solution is to add "allow_root" to your /etc/fstab and enable "user_allow_other" in your /etc/fuse.conf. See for more details: https://bugzilla.redhat.com/show_bug.cgi?id=1460203#c11
Thanks for the link Ondrej. I'm late to this bug, but my understanding is that the user-facing issue is that Nautilus offers an 'Eject' button which is tied by some underlying library to 'umount' instead of 'fusermount -u', regardless of whether the filesystem is fuse or not. If you're familiar with the internals of the problem, could you recommend a better upstream project to open a bug in?
I suppose that the proper fix here is to ensure that umount work for fuse filesystems without root permissions (as it is possible over fusermount). You can try to create issues on the following trackers: https://github.com/karelzak/util-linux/issues https://github.com/libfuse/libfuse/issues (please add here links to that issues) However, yes, GVfs is the component which calls umount after you press "Eject" button in Nautilus. I see two possibilities here: - do not set can_unmount=1 for fuse (so Nautilus won't show the "Eject" button) - add fusermount fallback for fuse Patches are welcome :-) Right place for those fixes is https://git.gnome.org/browse/gvfs/tree/monitor/udisks2/gvfsudisks2mount.c.
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gvfs/issues/133.