gvfs should unmount remote mounts on network disconnect

[Peter Kerekfy]

Binary package hint: gvfs

Problem: gvfs does not unmount remote shares if network disconnects. It leads to unusable mounts on my desktop after network is reconnected.

Expected behavior: unmount all remote shares on network disconnect

Workaround: manually unmount remote mounts before trying to access them after network disconnect/reconnect.

It is especially painful for roaming laptop users who always connect to different networks but want to access the same ftp/sftp/etc. server.

$ dpkg -l | grep gvfs| cat
ii gvfs 0.2.3-0ubuntu4 userspace virtual filesystem - server
ii gvfs-backends 0.2.3-0ubuntu4 userspace virtual filesystem - backends
ii gvfs-bin 0.2.3-0ubuntu4 userspace virtual filesystem - binaries
ii gvfs-fuse 0.2.3-0ubuntu4 userspace virtual filesystem - fuse server
ii libgvfscommon0 0.2.3-0ubuntu4 userspace virtual filesystem - library

$ cat /etc/lsb-release
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=8.04
DISTRIB_CODENAME=hardy
DISTRIB_DESCRIPTION="Ubuntu 8.04"

[Sebastien Bacher (seb128)]

Thank you for your bug report. How do you suggest detecting network disconnections? Using network manager? Waiting for a timeout? Having all the servers unmounted only because your connection dropped for a few seconds would be annoying too

[Peter Kerekfy (kerekfyp)]

These questions definitely need further investigation. :-)

First of all we need to know
 * which backends are able to recover from a temporary connection drop and
 * which backends are able to recover from a permanent connection drop with IP address change.

According to my experiences sftp backend recovers quite well from temporary drops but it fails to recover from IP address change. (since it is using ssh over TCP behind the scenes)

My very new idea: in if-up we should somehow detect whether or not the IP address has changed since the last connection and we should unmount remote shares only if it has changed.

Or we should provide a configuration option to distinct "roaming laptop mode" from "always connected desktop mode".

[nf2 (mail2nob)]

Just some thoughts:

Perhaps backends could have an advanced state-model, which allowes to enter a "disconnected due to connection problems" state, while still being mounted. Those states could be listed in GVolumeMonitor and be visible in the GUI (red emblems).

I wonder if reconnection should happen on demand (but that would probably cause hangs in the FUSE bridge), or be triggered from the outside (g_mount_repair())?

[Sebastien Bacher (seb128)]

The issue is similar to http://bugzilla.gnome.org/show_bug.cgi?id=515217

[Odin Hørthe Omdal (velmont)]

Waiting for this.

My use case: I started copying some pictures to my server. Seeing that it'd take over 2 hours, I connected the local network cable instead of wireless. When I saw that gvfs didn't migrate to the better connection, I disconnected from the wireless.

That made nautilus/gvfs hang very badly. And it never recovered (impossible to unmount as well), I had to kill gvfsd-sftp.

[Kristopher Ives (krisives)]

Bug will likely never be solved.

[Victor Yap (victor-yap)]

For users who use gvfs exclusively in a desktop environment:

This kind of issue is apparently somewhat addressed by a program called Gigolo (http://www.uvena.de/gigolo/index.html)

It makes it easier for me to do the reconnecting. More specifically, it doesn't care if the mount was left dangling; it's smart enough to sort that out simply by being asked to connect.

As for those who might be using gvfs to support CLI operations... maybe Gigolo's source code can reveal some potentially useful insights that can be carried into gvfs... http://git.xfce.org/apps/gigolo

[Victor Yap (victor-yap)]

See also : https://bugs.launchpad.net/ubuntu/+source/gnome-vfs/+bug/905497

[Michal Zubkowicz (michalzubkowicz)]

This bug is 4 years old!
Still persist in Trusty, prevents Nautilus from start