Comment 49 for bug 159031

https://bugs.launchpad.net/ubuntu/+source/sshfs-fuse/+bug/159031

Hi all,

I've been having this problem for quite some time. Whenever I accidentally touch an sshfs mounted directory which is unavailable, I have to run "killall sshfs" to get things working again. This often happens when I mount a directory on my home network and touch that directory while at work.

Right now my workaround is to use the "ServerAliveInterval" option without the "reconnect" option. This means that when the ssh connection is lost, sshfs exits (and unmounts the locally mounted directory). I then need to run sshfs again when I want to use the mount again (I could also use autofs, I assume).

In my opinion the main problem is that sshfs leaves the local directory in an invalid state while it is "trying to reconnect". No matter what happenes, it seems clear that at any given time the mounted directory should either be mounted or unmounted -- meaning available or unavailable. If the underlying ssh connection has been lost, it makes no sense to keep the directory mounted (and locking up system calls). It's like if you pull a usb disk out of your computer. The media is unavailable. It should be unmounted, no matter what. This is more or less the behaviour I get without the reconnect option.

I would suggest that the reconnect option should simply act as an "outer loop" around a non-reconnecting version of sshfs. The non-reconnecting version should close the ssh connection and unmount the local directory on disconnect. The reconnect loop should then both connect and mount when a connection to the remote host is available again.

Obviously it is also a problem that many applications don't properly handle IO errors, and some even have IO operations in their main loops. But sshfs, fuse, and ssh can't do much to fix this.

Best,
Kevin

Xubuntu 12.04 LTS
SSHFS version 2.3
FUSE library version: 2.8.6
fusermount version: 2.8.6
using FUSE kernel interface version 7.12