Properly unmount on Ctrl-C

[iFreilicht]

In my local network, I am running the following command (user and remote name anonymised):

sshfs myself@remote:/home.net/myself ~/remote
myself@remote's password:
<CTRL+C>

When using CTRL+C while entering the password, the directory will be mounted with an unconnected endpoint, so it's there but not usable:

mount -l
[...]
myself@remote:/home.net/myself on /home/myself/remote type fuse.sshfs (rw,nosuid,nodev,user=myself)
ls ~/remote
ls: transport endpoint is not connected: /home/myself/remote

This means that re-trying to mount it will fail:

sshfs myself@remote:/home.net/myself ~/remote
fuse: bad mount point `/home/myself/remote': Transport endpoint is not connected

The workaround is to manually unmount it and then try again:

fusermount -u remote
sshfs myself@remote:/home.net/myself ~/remote
myself@remote's password:

However, it would be nice if sshfs failed gracefully and automatically unmounted the non-connected directory for me.

[Nikratio]

Thanks for the report, and sorry for not responding for so long. I agree that it would be nice to handle better. Unfortunately I probably won't have time to work on this anytime soon, but I'll keep the bug open.

[yanir3]

Was this fixed? I was not able to reproduce this issue:

root@beer:/mnt# sshfs root@localhost:/root /mnt/sshfs
root@localhost's password: 
read: Interrupted system call
root@beer:/mnt# mount -l | grep sshfs
root@beer:/mnt# 

[Nikratio]

I'm not aware of any deliberate changes. It may have been a side effect of something else...

[kalvdans]

Looking at libfuse source code, it seems libfuse handles SIGINT specially and does a graceful exit with umount.

Another advice is to use option -o auto_unmount if you want the fusermount helper to unmount the filesystem when the sshfs process is hard killed. I use that flag in unit tests to not leave dangling stale mounts behind.

I think this issue can be closed.

[Nikratio]

I don't think libfuse is able to deal with the SSH process being Ctrl-C'ed, this will need treatment in sshfs.

[kalvdans]

You are right. Sorry for the noise, I didn't read the description properly.

[keithmendozasr]

@Nikratio if you can point me to where the ssh/sftp (on macOS "ssh" is the process listed) is called, I'll provide the fix to handle when the SSH process quits on a SIGINT.

[jyn514]

@keithmendozasr I did some code excavation and it looks like connect_remote is always called on startup. I think start_ssh is called the first time, although there's a branch in connect_remote so I'm not sure.

[bfleischer]

At least with regard to macOS, this issue has been addressed in macFUSE 4.6.2. Since 4.6.2 the FUSE_INIT handshake is performed synchronously during the mount(2) syscall. The mount operation will fail (and the volume will not be mounted as a result) unless SSHFS handles the FUSE_INIT handshake.