Nautilus sftp connection breaks spontaneously after a while, needing re-login to fix it

[Xtien]

When I have used an sftp connection for a while - started from Places/Connect to Server or from a bookmark - it breaks, typically after an hour or so. The only way to get an sftp connection to that server again is to re login to my computer. The error message I get is

Could not open location 'sftp://......'

DBus error org.freedesktop.DBus.Error.NoReply: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken

Sometimes when this happens, my computer freezes for about 60 seconds.

I have Ubuntu 9.04 64 bits - error happened on Hardy also - on a computer with an AMD64 processor.

[Kurt Wall (kwall)]

Is the sftp connection active? That is, is a download active or is the session just sitting there. If the session is idle, I would expect the server side to close the connection due to inactivity. Does this happen with all sftp sessions or at specific sites?

[Xtien (xtien)]

The session is dead. Nothing is happening, it typically goes dead after it's been open for a while and I haven't been using it. I wouldn't mind it dying, if I can start a new connection, but I can't. It takes a while before I can start an sftp connection to the same host again, unless I re-login.
I have only noticed this behavior with one site - my own server - because that's the only site I regularly use sftp with. I haven't seen this behavior when I use my laptop, which has Ubuntu 9.04 also, on 32 bits.

[Kurt Wall (kwall)]

Xtien, thanks for the reply. As a first step, I'm assigning this to the openssh package. Are there logs from your server that show the connection attempt(s) and the failing connection? Regards, Kurt

[rg (rob-themayfire)]

I am having this issue as well, on Ubuntu 9.04. And I happen to know that the sftp server I am logged into does indeed timeout after a certain period. So I don't hold Ubuntu responsible for the timeout, only for how it handles it.

On Intrepid I sort of remember getting an immediate error when I tried to access the timed-out connection, and I was able to re-establish a new connection by simply closing and reopening it in nautilus.

Now on 9.04 it freezes nautilus (or, if I used the Places menu, my entire desktop!) for one minute before returning the org.freedesktop.DBus.Error.NoReply error that Xtien mentioned. And I haven't yet found a way to reestablish the sftp connection without rebooting.

[rg (rob-themayfire)]

Updates:

1. In the time it took me to write up that last comment, something reset itself, and I was able to reconnect. This is after several failed attempts 10-15 minutes ago. I didn't change anything, I was just here typing.

2. I'm actually not completely sure if it "freezes" nautilus, though it does freeze my desktop, and either way it takes a minute to get the error.

3. Until there's a fix I'll probably use this workaround:
http://ocaoimh.ie/2008/12/10/how-to-fix-ssh-timeout-problems/

[Chuck Short (zulcss)]

Hi,

I was wondering if you were still having this problem?

Thanks
chuck

[Xtien (xtien)]

Yes, it's still happening. It's like the server closed the connection, but the client refuses to re-login until after five or ten minutes.

[acacha (sergi-tur)]

http://ubuntuforums.org/showthread.php?t=573863

[fubarbundy (launchpad-mailtic)]

Yes, Nautilus'/GVFS' handling of SFTP timeouts is atrocious. Not sure how this could happen with a brand-new 21st century rewrite of a network backend, but nevermind.

As a workaround, try the following in a terminal:

gvfs-mount -l

(to list your GVFS mounts)

Then

gvfs-mount -u "sftp://your-server/"

to unmount the offending location and be able to re-connect/use Nautilus again.

[Brian Curtis (bcurtiswx)]

I would like to know if this is still a problem on Karmic?

[fubarbundy (launchpad-mailtic)]

It is.

[Xtien (xtien)]

I confirm.

[Brian Curtis (bcurtiswx)]

Ok, will someone with the problem please type "apport-collect -p nautilus 377322" in their terminal.

[fubarbundy (launchpad-mailtic)]

Architecture: amd64
DistroRelease: Ubuntu 9.10
Package: nautilus 1:2.28.1-0ubuntu2
PackageArchitecture: amd64
ProcEnviron:
 SHELL=/bin/bash
 LANG=en_GB.UTF-8
ProcVersionSignature: Ubuntu 2.6.31-15.50-generic
Uname: Linux 2.6.31-15-generic x86_64
UserGroups: adm admin cdrom dialout lpadmin plugdev sambashare
XsessionErrors:
 (gnome-settings-daemon:2036): GLib-CRITICAL **: g_propagate_error: assertion `src != NULL' failed
 (polkit-gnome-authentication-agent-1:2141): GLib-CRITICAL **: g_once_init_leave: assertion `initialization_value != 0' failed
 (nautilus:2129): Eel-CRITICAL **: eel_preferences_get_boolean: assertion `preferences_is_initialized ()' failed
 (gnome-panel:2128): Gtk-WARNING **: gtk_widget_size_allocate(): attempt to allocate widget with width -3 and height 24
 (nautilus:9315): Eel-CRITICAL **: eel_preferences_get_boolean: assertion `preferences_is_initialized ()' failed

[Xtien (xtien)]

Architecture: amd64
DistroRelease: Ubuntu 9.10
Package: nautilus 1:2.28.1-0ubuntu2
PackageArchitecture: amd64
ProcEnviron:
 SHELL=/bin/bash
 PATH=(custom, user)
 LANG=en_US.UTF-8
ProcVersionSignature: Ubuntu 2.6.31-15.50-generic
Uname: Linux 2.6.31-15-generic x86_64
UserGroups: adm admin cdrom dialout lpadmin plugdev sambashare

[TimMadden (timmadden)]

I believe I have this too. Mostly an annoyance. My workaround has been to open a terminal window, do "ps aux |grep sftp" and then kill the pid for sftp session. Sure do wish it would kill itself once it has expired...

[Andrew Somerville (andy16666)]

I'm having the same problem. It makes it hard to work on a file from a remote machine over a long period of time. If I look away for even a short time gedit will freeze and I'll have to wait for it to time out before I can continue working on my code. I can provide any additional information required.

[Schneidersoft (schneidersoft)]

I am also having this problem.

Not just with sftp but also with ssh connections. Working on a remote machine for something like web development becomes frustrating. When working with a remote file in gedit, if left alone for too long the connection will break, and gedit will freeze. ssh connections simply freeze the terminal.

[Murray Cumming (murrayc)]

This is still a problem with Ubuntu Natty (currently unstable). It's a huge annoyance to me.

[Andrew Somerville (andy16666)]

Agreed. The lack of a reliable SCP function in nautilus renders Ubuntu virtually useless for some software development tasks. The level of annoyance created by this bug cannot be overstated.

[Xtien (xtien)]

Also in Natty Narwhal. Is there anything I can do to help fix this?

[Andrew Somerville (andy16666)]

#5 is a decent workaround.

[Chris Gilbert (marvincomputers)]

This bug is extremely annoying to me when performing certain operations. Is there anything I can do to help fix it? I also get it using FTP, windows shares, and in fact, any sort of GVFS connection.

To create the problem, I just do the following:

1. Add a new network server connection through the 'Connect to Server' dialog.
2. Add a bookmark
3. Provide credentials, and choose 'remember forever' (it doesn't matter if you choose another option).
4. Browse to nautilus bookmark.

Now, you can open files, copy, save, and things work fine.

5. Leave connection open (a few minutes is usually enough for many servers, depending on settings)

I, and many other people do this all the time - for instance when doing webdesign, development and so on, I like to be able to work directly on the server over SSH or FTP. Not an unusual use case.

6. Try to save, browse or open a new Nauiltus window to the GVFS location. You will receive:

Could not open location 'sftp://......'

DBus error org.freedesktop.DBus.Error.NoReply: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken.

The desired behaviour is for this error to be handled, and the connection automatically created. Nautilus already has the credentials - there isn't a use case I can see where this error is useful to anything but irritating the user...

We should *expect* connections to be broken - for instance over wifi, or with other unreliable network connections. It is not an unusual occurrence to lose connection to the server for any number of reasons. Providing this doesn't actually happen whilst copying a file, saving etc, then it should be easy enough to automatically reconnect, and drop the existing connection. In fact, even if it drops a connection whilst copying or saving, it would be possible to attempt a reconnection with a user prompt. It makes much better sense than throwing an ugly error for no good reason :)

I am happy to help resolve this - it's ultimately very annoying for a great many people I imagine...

I will take a look at the code, and see if I can understand it well enough to contribute that way.

[Murray Cumming (murrayc)]

I wonder if this upstream bug (with patches) is relevant: https://bugzilla.gnome.org/show_bug.cgi?id=500538

I was sure I had seen some other upstream (GNOME) bug about this, but I can't find it now.

[Murray Cumming (murrayc)]

I thought I'd use this long-lived very-annoying bug to test freedomsponsors.org. It at least gives us the chance to promise our money to whoever fixes it:
http://www.freedomsponsors.org/core/offer/36/nautilus-sftp-connection-breaks-spontaneously-after-a-while-needing-re-login-to-fix-it

[Tony Calleri França (tonylampada)]

@murrayc you might as mention that you placed a US$ 200 bounty for this bug there :-)
Well, now you don't need to :P

[aktiwers (aktiwers)]

Im also having this bug! Worst bug ever

[aktiwers (aktiwers)]

I think I have found a solution to this problem - and I don't think its a bug anymore.

Trying on another router, I found it not to disconnect anymore. The router causing the problem I had no access to (since its not mine), but reading through some man pages I found that

Editing the following config file: /etc/ssh/ssh_config

and add this line:
ServerAliveInterval 60

Fixed it for me. Or should have fixed it, but didnt. Puttin the interval to 10 instead did fix it! :)

But 60 should be enough for must people.

[Timothy Arceri (t-fridey)]

Changed project to gvfs and linked to upstream bug. Looks like there was a half finished patch for this in 2008

[Murray Cumming (murrayc)]

I removed the bug watch for https://bugzilla.gnome.org/show_bug.cgi?id=500538 because that's for gnome-vfs, which is deprecated and no longer used by Nautilus, having been replaced by gvfs.

[Timothy Arceri (t-fridey)]

I have created a patch on the upstream bug but I'm having difficulty reproducing the issue on my machine. Is someone able to help me with testing? I can either create the deb packages for you or create a patch that you can use to build your own. I currently have debs built for 12.10 but can create them for 12.04 if need be.

[Murray Cumming (murrayc)]

Sure, thanks, I can test on Ubuntu Raring. A PPA would be the nicest way for me to do that.

[Timothy Arceri (t-fridey)]

Ok, PPA is ppa:t-fridey/t-arceri-gvfs-ppa

Please test with no remote files open for first timeout. Hopefully the sftp mount will be unmounted and you will be able to remount it.

Next please test with a remote file open when the timeout happens hopefully again the sftp mount will be unmounted. (you may receive and error message from the program with the open file this is expected.)

Let me know how it goes.

[Timothy Arceri (t-fridey)]

Sorry Murry I seemed to have misread your previous post. For some reason I though you were using precise. I have updated the ppa with a new Raring build based on my conversations with the upstream devs. Hopefully this one should do the trick. Please let me know how it goes.

[Murray Cumming (murrayc)]

Timothy, thanks. I'm installing it now and I'll see how it goes over the next few days.

[Timothy Arceri (t-fridey)]

@murrayc Any luck with the ppa?

[Murray Cumming (murrayc)]

Timothy, unfortunately, I've had this problem again at least twice since installing the packages from your PPA at https://launchpad.net/~t-fridey/+archive/t-arceri-gvfs-ppa

Then again, I can't be quite sure that I really still have your packages installed. I think you should use a suffix on the package version numbers.

[Timothy Arceri (t-fridey)]

Ok, thanks Murray. This is the first PPA I have created so I wasn't sure how to give the package a different name so that it would be the preferred version of gvfs. Any tips are welcome.
You should still have my version installed as there hasn't been an official release in a while. You can check with the command 'apt-cache policy gvfs' you should have 1.16.1-0ubuntu19

Looks like I'm going to have to figure out how to reproduce the issue myself. I'll might start by trying the steps in this bug as it seems related: https://bugzilla.gnome.org/show_bug.cgi?id=325979

[Murray Cumming (murrayc)]

Yes, I have that version installed.

[Timothy Arceri (t-fridey)]

Hi Murry/Anyone else that can reproduce this bug,

I have been trying all morning to reproduce your issue with a stock version of gvfs and have so far had no luck (although I may have uncovered some other rare bug corner cases). Can you please provide a little more information.

1. Are you on a Wired or Wireless network?
2. In the time you have connected to the sftp location is it likely that your wireless/ or even wired connection has dropped out and reconnected?
3. If you are reconnected do you always have the same IP address?
4. What exactly are you doing when you get the error message?
5. Do you still see the sftp location mounted in Nautilus after you get the error message?
6. Do you have any other Network issues when the error occurs? i.e is you network connecting working fine for everything else?
7. Is there anything else you can think of that might be helpful with reproducing this?

[Timothy Arceri (t-fridey)]

Ok, after doing some reading about the TCP keep alive option I think I have found the explanation for the issue you describe. For reference here is an extract from: http://tldp.org/HOWTO/TCP-Keepalive-HOWTO/overview.html

---------------------------------------------------------------------------------------------------------------------------------------------------------------------------
2.4. Preventing disconnection due to network inactivity

The other useful goal of keepalive is to prevent inactivity from disconnecting the channel. It's a very common issue, when you are behind a NAT proxy or a firewall, to be disconnected without a reason. This behavior is caused by the connection tracking procedures implemented in proxies and firewalls, which keep track of all connections that pass through them. Because of the physical limits of these machines, they can only keep a finite number of connections in their memory. The most common and logical policy is to keep newest connections and to discard old and inactive connections first.

Returning to Peers A and B, reconnect them. Once the channel is open, wait until an event occurs and then communicate this to the other peer. What if the event verifies after a long period of time? Our connection has its scope, but it's unknown to the proxy. So when we finally send data, the proxy isn't able to correctly handle it, and the connection breaks up.

Because the normal implementation puts the connection at the top of the list when one of its packets arrives and selects the last connection in the queue when it needs to eliminate an entry, periodically sending packets over the network is a good way to always be in a polar position with a minor risk of deletion.

    _____ _____ _____
   | | | | | |
   | A | | NAT | | B |
   |_____| |_____| |_____|
      ^ ^ ^
      |--->--->--->---|----------- SYN ------------->--->--->---|
      |---<---<---<---|--------- SYN/ACK -----------<---<---<---|
      |--->--->--->---|----------- ACK ------------->--->--->---|
      | | |
      | | <--- connection deleted from table |
      | | |
      |--->- PSH ->---| <--- invalid connection |
      | | |

---------------------------------------------------------------------------------------------------------------------------------------------------------------------------

I guess the first step from here is to see if some firewall software can be used to drop these connections after say 30 seconds so that this scenario can be reproduced more easily then a fix for gvfs can be worked on.

[Timothy Arceri (t-fridey)]

Changed upstream bug. The old one is probably still part of the solution but the new one more accurately describes this issue.

[Timothy Arceri (t-fridey)]

Hi again Murray/others how can reproduce,

While I still have not found a way for me to reproduce this issue I have created a new ppa for you to try 1.16.1-0ubuntu21.

This may help as it will cause the backend to exit more cleanly when the underlying SSH process dies. Although I cant be sure when or if this call is made under these circumstances until its tested. If this latest patch does not work its possible that its Openssh that is causing the 10-15 minute delay in the connection re-establishing rather than gvfs.

[Murray Cumming (murrayc)]

> 1. Are you on a Wired or Wireless network?

Wireless

> 2. In the time you have connected to the sftp location is it likely that your wireless/ or even wired connection has dropped out and reconnected?

Yes, but I don't think that's always the case.

> 3. If you are reconnected do you always have the same IP address?

Yes.

> 4. What exactly are you doing when you get the error message?

Browsing files via Nautilus.

[Murray Cumming (murrayc)]

> I have created a new ppa [package] for you to try 1.16.1-0ubuntu21.

I've had that installed, but I had the problem again today.

[Timothy Arceri (t-fridey)]

Hi Murray,

Thanks for all the feedback. I managed to configure my router to drop connections after 1 minute in order to try reproduce the issue however. I think we need to clear up exactly what your issue is. The raring version of Nautilus seems to handle things much nicer than previous versions there is no freezing and the error messages seem to be a little bit more refined.

Anyway the point is the issue has changed from the initial post. Can you please describe what your problem is? In my test once the timeout drops the connection and I try to navigate Nautilus I get an error message saying:
"Opps something went wrong.
Unhandled error message: Internal error: The underlying SSh process died"
Is this the message you are getting? If so what is the solution you are after? Do you just want it to try auto reconnect?

If you are getting a different message can you please describe exactly whats happening, and the solution you want so that I know what I'm working toward.

Thanks for you time,
Tim

[Murray Cumming (murrayc)]

I haven't thoroughly tracked what messages I see now, but it certainly seems much better.

I do now get that ""Opps something went wrong." message about "the underlying SSh process died", and I can then just try again, whereas before I had to explicitly kill a process. I don't know for sure if that's never necessary any more, but I'll report here if I experience it.

Even if killing the process is still sometimes necessary, things do seem much better, though obviously the "Oops something went wrong message" doesn't need to be shown to the user if a reconnection can be done without even mentioning it.

[Julien Olivier (julo)]

Seems like the bug is back in Nautilus 3.34 and Ubuntu 19.10 :(