after years i *really* have enough of the behavior that sshfs, mtp and other fuse-mounts a) can't be unmounted as user b) needs to be unmonuted in a root shell while c9 root even don't have access to the data in the mountpoint [harry@srv-rhsoft:~]$ simple-mtpfs -l 1: ZTEV790/Blade 3 [harry@srv-rhsoft:~]$ simple-mtpfs --device 1 /mnt/mtp/ [harry@srv-rhsoft:~]$ umount /mnt/mtp/ umount: /mnt/mtp/: Permission denied _____________________________ that is just pervert: [root@srv-rhsoft:~]$ ls /mnt/mtp/ /usr/bin/ls: cannot access '/mnt/mtp/': Permission denied [root@srv-rhsoft:~]$ umount /mnt/mtp/ [root@srv-rhsoft:~]$ _____________________________ see also https://bugs.launchpad.net/ubuntu/+source/util-linux/+bug/1507298
I would not expect umount to work as a non-privileged user. fusermount -u should work fine though. If that does not work, please reopen.
If i can mount fuse stuff from /etc/fstab as a normal user I simply expect be able use unmount to unmount it afterwards
Then file a bug against util-linux. That's how it has worked since forever. Nothing in fuse prevents umount from working that way.
Then re-assign it since it's NOT obvious which piece of package is responsible for what behavior or does util-linux also prevent any access for root on a fuse mount point with the single exception of umount
umount _always_ requires root privs. I do not believe it even checks to see if it is necessary. This is one of the reasons that fuse upstream built fusermount. fusermount -u should do exactly what you want. If you're unwilling to use it, then you're on your own.
And THAT attitude is the reason you can't install Linux on anybody elses machines - it is a unacceptable user experience when you have to deal every few weeks or months with fuse mount points that the mount command can handle them proper but for umount you need to remember a different command And that said from a pure tech guy which did things with Fedora based servers long before anybody out there considered Fedora at all be usable for that tasks
You're one to speak on attitude. Either file a bug against util-mount or leave me be.
(In reply to Tom "spot" Callaway from comment #7) > You're one to speak on attitude. Either file a bug against util-mount or > leave me be. util-linux, rather.
What about
Surely when you fool close a bug instead of assign it to the component which you think is responsible
The permissions evaluation is done by filesystem and uid/git could be re-mapped on another users (this is pretty common for example for NFS, etc). The first thing we do in umount(8) is to verify that non-root user has permissions to access path specified on umount(8) command line. For this check umount(8) drops the eUID=0 (it's suid) and switch to real UID, then than it calls realpath() (this function is based on lstat()). Unfortunately, if you mount fuse without "allow_root" mount options than this path verification fails... (not sure why, I have to talk about it with fuser maintainer). The solution is to add "allow_root" to your /etc/fstab and enable "user_allow_other" in your /etc/fuse.conf.
This message is a reminder that Fedora 25 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 25. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '25'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 25 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 25 changed to end-of-life (EOL) status on 2017-12-12. Fedora 25 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.