Oh, and after doing what one should have already done in the beginning, a quick web-search, I found this:
https://serverfault.com/questions/30679 … connection
EDIT: Sorry, it seems like you already use the reconnect option.
]]>By the way, have you tried x33a's suggestion? It looks promising to me.
]]>Have you tried, whether disabling systemd.automount helps?
E.g. by disabling the associated automount unit, probably home-myUser-someShare.automount?
By the way, you assumed, x-systemd.automount would try to mount the filesystem, which implies that it has been properly unmounted before.
Is this true?
To me, it sounds rather unlikely, since any process operating on it, i.e. a shell with $PWD inside the filesystem should prevent that. And if there are programs hanging due to this, I suspect they use the filesystem.
Or am I somehow wrong?
x-systemd.device-timeout=
Configure how long systemd should wait for a device to show up before giving up on an entry from /etc/fstab. Specify a time in seconds or explicitly append a unit such as "s", "min", "h", "ms".
Note that this option can only be used in /etc/fstab, and will be ignored when part of the Options= setting in a unit file.
But it's not working. I get the same hangs once the mount point dies.
]]>However, if you believe this setting to be the culprit, you could test if switching to noauto and automounting the share upon login helps.
Actually I could even imagine, that systemd's automount will help in case the connection is broken by trying to remount the share properly.
I was sometimes forced to kill the sshfs process before being able to remount the shared folder.
By the way:
systemd.automount(5)
TimeoutIdleSec=
Configures an idle timeout. Once the mount has been idle for the
specified time, systemd will attempt to unmount. Takes a
unit-less value in seconds, or a time span value such as "5min
20s". Pass 0 to disable the timeout logic. The timeout is
disabled by default.
Possibly changing this to a lower value may also help.
Though you would probably have to create a custom automount unit.
Is linux really that... un-robust when it comes to losing the connection to a share?
At least sshfs, apparently.
I had similar issues with my local Raspberry Pi sharing /srv, so I switched to editing all the files locally and pushing them via a custom vim command.
Obviously this is not an option for you, but have you tried any other solution, such as NFS?
Note: This can cause problems with resources getting locked if the connection to the share is lost. When trying to access the folder, programs will get locked into waiting for a response, and either the connection has to be restored or the process has to be forcibly killed before unmounting is possible. To mitigate this, only use if you will always be connected to the share, and do not use your home folder or other commonly used folders lest your file browser reads ahead into the disconnected folder
Which is exactly the situation I'm in without autofs atm. Is linux really that... un-robust when it comes to losing the connection to a share?
]]>myuser@192.168.178.2:/data/SomeShare /home/myuser/SomeShare fuse.sshfs nofail,x-systemd.automount,idmap=user,_netdev,identityfile=/home/myuser/.ssh/id_rsa,allow_other,default_permissions,uid=1000,gid=1000,umask=0,reconnect,cache=no,kernel_cache,ciphers=arcfour,compression=no
What I'm used to is the mount point simply returning an error on access and doesn't affect browsing otherwise if it's not mounted.
Is there a way to make it work like that in this case as well?