Hello all, I have a regular, openrc-gnome profile machine, and have had issues with this particular bug for months now, I finally posted a pull request. https://github.com/libfuse/libfuse/pull/716 all the details are on github, basically, automount is not working with fuse in this case. What is surprising is that I had a plasma vm which worked just fine for a few months, and didn't need sshfs any where else, but after rebuilding the system, and working on other systems (profiles) I realized that this fuse issue hadn't gone away, and that its either a weird flaw nobody is complaining about, or perhaps its to do with OPENRC/Gentoo and perhaps the way fuse or autofs is built through the ebuild system. At any rate, I have sys-fuse working for me, and autofs works just fine after a 1 liner. Reproducible: Always Steps to Reproduce: 1. using mount -t fuse.sshfs works 2. using sshfs .... works 3. using auto.sshfs (autofs) never works. Actual Results: automount is passing fuse an "-n" argument which fuse is not coded to be able to handle, for which fuse is breaking (sshfs) and causing the mount never to happen. Dec 19 01:49:24 localhost automount[53618]: >> fuse: unknown option(s): `-n' Expected Results: sshfs works with autofs Dec 19 01:49:24 localhost automount[53618]: mount(generic): calling mount -t fuse.sshfs -o uid=0,gid=0,allow_other root@127.0.0.1:/root /test Dec 19 01:49:24 localhost automount[53618]: spawn_mount: mtab link detected, passing -n to mount Dec 19 01:49:24 localhost automount[53618]: >> fuse: unknown option(s): `-n' Dec 19 01:49:24 localhost automount[53618]: mount(generic): failed to mount root@127.0.0.1:/root (type fuse.sshfs) on /test Dec 19 01:49:24 localhost automount[53618]: dev_ioctl_send_fail: token = 27 Dec 19 01:49:24 localhost automount[53618]: failed to mount /test
I will add, that I attempted to build w/ Meson, and configured both with and without disable-mtab set. And I saw no difference in results. Project options Current Value Possible Values Description --------------- ------------- --------------- ----------- disable-mtab false [true, false] Disable and ignore usage of /etc/mtab
to test : ------------------------------------------------------- /etc/autofs/... modify auto.master /srv/sshfs/ /etc/autofs/auto.sshfs --ghost,uid=0,gid=0,--timeout=60 add to auto.sshfs test -fstype=fuse.sshfs,allow_other root@127.0.0.1:/root ensure you have a passwordless authorized key for root@localhost mkdir -p /srv/sshfs/test/ should work - sshfs root@127.0.0.1:/root /srv/sshfs/test/ mount -t fuse.sshfs -o uid=0,gid=0,allow_other root@127.0.0.1:/root /srv/sshfs/test [doesn't work for me, via autofs ] (no other manual mounts) ls /srv/sshfs/test/ OR (-n) sshfs root@127.0.0.1:/root -n /srv/sshfs/test/ [ remedy ] cd /usr/src/ git clone git clone https://github.com/pcxmac/libfuse.git cd libfuse mkdir build cd build rc-service autofs stop meson .. ;ninja;meson test;cp lib/libfuse3.so.3.12.0 /usr/lib64; cp util/fusermount3 /usr/bin;cp util/mount.fuse3 /usr/sbin rc-service autofs restart [ does work now ]
final addition, for the record mount (automount) does know about -n, but fuse is not coded to handle such a flag. Here is the man page for [mount]'s understanding of -n -n, --no-mtab Mount without writing in /etc/mtab. This is necessary for example when /etc is on a read-only filesystem.
Sorry, it's not 100% clear to me what the request is here. Is this a heads up about the upstream PR and a request for us to backport it to fuse in Gentoo?
I am filing the bug because it's a real issue for me, I am not sure why its not an issue for other people, although I have seen people complain about it through google search results. So the report is for other people to add in on, and if anyone wants / has the time to confirm the bug exists. I use gentoo/openrc + zfs on root, to be honest SSHFS just does not work for me at least not for about half a year, and this issue could have precipitated due to recent changes in the way autofs uses mtab, how mtab works, etc... What I do know is that one line change, allows fuse to work with the SSHFS in mounting the entry successfully, and flawlessly. I will admit I haven't built a series of tests to see if this breaks anything else, though, I do believe that FUSE will run that flag to a 'null' function, and discard it 'effectively'.
The code change has been adopted, and [lib]fuse has been updated. SSHFS works like it should. according to my recent limited testing.
