Enable reconnect by default

[felisucoibi]

I mean, it selfdisconnect so often, it hangs computer, so often you have to restart the conection manually? sshfs could be perfect if users dont have to care about stability.

[Harvie]

@felisucoibi put something like this to fstab:

sshfs#[email protected]:/content/	/mnt/srv	fuse	defaults,user,allow_other,reconnect,delay_connect,ConnectTimeout=5,ServerAliveInterval=5,IdentityFile=/root/.ssh/id_rsa_storage 0 0

This fixed all my problems with connection stability, i even use it on laptop roaming between networks without any issues. I watch movies using this mountpoint.

Trick is in these settings: reconnect,delay_connect,ConnectTimeout=5,ServerAliveInterval=5

I really think, these should be default sshfs options!!! Can you please make it so? I never had any issues with this setup so far (using it for years). It makes everything hassle free.

[Nikratio]

Thanks for your interest in SSHFS! As far as I can tell, this is a question about how to use SSHFS rather than a bug report. Could you please send your question to SSHFS mailing list (https://lists.sourceforge.net/lists/listinfo/fuse-sshfs), instead of using the issue tracker? I'd like to reserve use of the latter to actually track issues and not use it for discussion.

Thanks!

[Harvie]

I think this is about not so robust default setings. I think defaults should be changed and therefore this can be handled as issue.

[Nikratio]

I see. Well, I think enabling reconnect by default can't hurt. The settings for ConnectTimeout and ServerAliveInterval are pretty arbitrary though - while they may work for you, they may be inappropriate for someone else. Finally, enabling delay_connect by default would be downright confusing.

[Harvie]

@Nikratio Would it be possible to enable delay_connect by default only for mounting from fstab? It makes lots of sense when used with fstab, since it's quite common that fstab is mounted before network is started. Especially when you use wifi.

Do you think that timeout/reconnect after 5 seconds is too often? Maybe 10 seconds would be better for all users.

[kalvdans]

At work we are using reconnect,delay_connect,_netdev on all our fstab mounts. I'm not sure they should be default though, as we would have to invent silly looking noreconnect and nodelay_connect options instead to get the other behaviour.

[Harvie]

as we would have to invent silly looking noreconnect and nodelay_connect options instead to get the other behaviour.

Why would someone mount sshfs in nonreconnect mode? If i don't want my filesystem to be mounted i just unmount it. Can't really see the usecase for someone deliberately configuring filesystem to be less reliable. If somebody has need for non-reliable solution, then it's already silly looking case and might be prepared to investigate silly looking options.

[kalvdans]

One common usecase where you want a single connection is when a password is required for the connection. Then you want to enter it once when sshfs starts, and don't want sshfs to try again since it has lost the access to the terminal.

[ghost]

There's definitely cases where reconnecting is a bad idea. You may want to know there was a failure.

I know for most people reconnecting automatically is good, but in some cases it's more intuitive to specify reconnecting than specify not reconnecting.

[Harvie]

You may want to know there was a failure.

Can you give me an example? I guess in these cases you might want to watch the logs, so you would know about the reconnects anyway...

[ghost]

Can you give me an example? I guess in these cases you might want to watch the logs, so you would know about the reconnects anyway...

Maybe you have some things that run on top of the sshfs. Because sshfs never gives up, all of those services are hung thinking there's a filesystem underneath them. And if it can never reconnect, it's a problem. I know it's bad to fail, but sometimes infinity is worse.

It might also not be immediately obvious that sshfs is disconnected when the process is still running. While yes, debugging output would show that, it's just making assumptions. I like things that do as little as possible and if I want them to do more, I tell them to do more.

Kind of like how you always want gas in your car. But filling up with gas takes time. My car could fill itself up, but it might catch me off guard. Maybe not the best analogy.

[felisucoibi]

There's definitely cases where reconnecting is a bad idea. You may want to know there was a failure.

I know for most people reconnecting automatically is good, but in some cases it's more intuitive to specify reconnecting than specify not reconnecting.

There are, but usually somebody expect to keep a stable file system over sshfs, this is the normal use and should be default, my opinion of course.

[Harvie]

My use case is to mount NAS on my laptop. So i want it to be immediately available when i travel across wifi networks or wake the system from being suspended in RAM without having to take manual action. But i also use the same settings on servers to make sshfs mountpoint survive network outages and remote server reboots.

Having at least these as defaults might make sense to most people: ConnectTimeout=5,ServerAliveInterval=5 Or just add some option as keep_connected which will be shorthand for reconnect,delay_connect,ConnectTimeout=5,ServerAliveInterval=5

[Wynadorn]

Possible solution? https://help.ubuntu.com/community/Autofs

autofs kernel-based automounter for Linux

autofs is a program for automatically mounting directories on an as-needed basis. Auto-mounts are mounted only as they are accessed, and are unmounted after a period of inactivity. Because of this, automounting NFS/Samba shares conserves bandwidth and offers better overall performance compared to static mounts via fstab.

See chapter 6.2.1. SSHFS file system

[Harvie]

Possible solution? https://help.ubuntu.com/community/Autofs

No.

I am happy with how the sshfs works by itself. it can reconnect without any issues with my configuration. Absolutely no need for autofs. only issue is that the default settings are not really robust. i think sshfs should by default be configured like this, i am using this for years and it is absolutely perfect

sshfs#[email protected]:/data/	/mnt/data	fuse	defaults,user,ro,nofail,_netdev,allow_other,reconnect,delay_connect,ConnectTimeout=5,ServerAliveInterval=5,TCPKeepAlive=no,IdentityFile=/root/.ssh/id_rsa_example 0 0

it never happened to me that i would have trouble accessing the files from my laptop as long as i can ping the server, even after hopping between offices and wifi networks. obviously this is intended for interactive access to personal files, not for running database engine on top of it. but in that case you probably should not use wifi anyway...

[rulatir]

Maybe you have some things that run on top of the sshfs. Because sshfs never gives up, all of those services are hung thinking there's a filesystem underneath them. And if it can never reconnect, it's a problem. I know it's bad to fail, but sometimes infinity is worse.

I see no conflict between trying to reconnect to the "data source" indefinitely and failing individual application requests while the reconnection hasn't succeeded yet. You CAN have failures AND infinity.