SSHFS reports success on specific failure

[alkisg]

To reproduce this, two root shells in two terminals are needed:

root@term1: sshfs user@server: /tmp/dir
root@term2: fusermount -u /tmp/dir
root@term1: NOW enter the password

At that point, the password in term1 gets accepted, sshfs shows no errors, the return code is 0, and yet /tmp/dir is not mounted.

Someone might ask, "ok, this is indeed a race condition, but why would you fusermount -u at that point"?
The answer is that we're using sshfs-based homes; so at pam_close we need to fusermount -u /home/username; at that point, we can't detect if a new instance of sshfs "has the intention to mount after the password will be entered".

In any case, since the mount fails, it could at least report failure.

Feel free to close this issue if there's no manpower to work on it, I just wanted to reference it in the LTSP code base in case some future LTSP developer or user will want to offer a patch. Thanks!

[alkisg]

Btw, mountpoint /home/username blocks and waits until the password is entered.
Fortunately grepping /proc/mounts gives an indication of when "sshfs intends to mount...", so we'll use that for a quick workaround.

[jakobcornell]

I can't reproduce this on Linux; the unmount command fails with Device or resource busy, and the filesystem remains mounted after authenticating. Do you still have this issue? Any idea what might be causing the discrepancy?

[alkisg]

Which Linux distro/version and sshfs version?

Usually that message is shown when one "cd"s to the mounted directory and it's in use; but in the test case that I described above, I didn't use "cd" anywhere...

What's the output of sudo lsof /tmp/dir when it's busy?

[jakobcornell]

I got that result on both Debian stable sshfs 2.10 and a build of the current master tree. Shouldn't have been anything open in the mountpoint since I ran the commands outside it. But it looks like the stat syscall fails with Permission denied when I try lsof or fuser, so I can't really be sure. After aborting the sshfs command there aren't any users of the mountpoint.

[Nikratio]

SSHFS does not have any active, regular contributors or developers. The current maintainer continues to apply pull requests and tries to make regular releases, but unfortunately has no capacity to do any development beyond addressing high-impact issues. When reporting bugs, please understand that unless you are including a pull request or are reporting a critical issue, you will probably not get a response.

To prevent the issue tracker from being flooded with issues that no-one is intending to work on, and to give more visibilty to critical issues that users should be aware of and that most urgently need attention, I will also close most bug reports once they've been inactive for a while.

Please note that this isn't meant to imply that you haven't found a bug - you most likely have and I'm grateful that you took the time to report it. Unfortunately, SSHFS is a purely volunteer driven project,
and at the moment there simply aren't any volunteers.

[alkisg]

@jakobcornell, I just tested on Debian Buster and I was able to reproduce it,
but I needed to run those commands as root, not as a user.

I just edited the original message to include that information.