Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Enable reconnect by default #101

Open
felisucoibi opened this issue Oct 11, 2017 · 15 comments
Open

Enable reconnect by default #101

felisucoibi opened this issue Oct 11, 2017 · 15 comments
Assignees

Comments

@felisucoibi
Copy link

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
Copy link

Harvie commented Oct 20, 2017

@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
Copy link
Contributor

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
Copy link

Harvie commented Oct 20, 2017

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 Nikratio self-assigned this Oct 21, 2017
@Nikratio Nikratio changed the title is going to be stable for heavy loads sshfs? Enable reconnect by default Oct 21, 2017
@Nikratio
Copy link
Contributor

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.

@Nikratio Nikratio reopened this Oct 21, 2017
@Harvie
Copy link

Harvie commented Oct 21, 2017

@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
Copy link
Contributor

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
Copy link

Harvie commented Oct 19, 2019

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
Copy link
Contributor

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
Copy link

ghost commented Nov 30, 2019

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
Copy link

Harvie commented Nov 30, 2019

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
Copy link

ghost commented Nov 30, 2019

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
Copy link
Author

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
Copy link

Harvie commented Dec 1, 2019

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
Copy link

Wynadorn commented Jan 18, 2022

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
Copy link

Harvie commented Jan 18, 2022

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...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants