gvfs should unmount remote mounts on network disconnect

Bug #223636 reported by Peter Kerekfy on 2008-04-28
This bug affects 17 people
Affects Status Importance Assigned to Milestone
gvfs (Ubuntu)
Ubuntu Desktop Bugs

Bug Description

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

Sebastien Bacher (seb128) wrote :

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

Changed in gvfs:
assignee: nobody → desktop-bugs
importance: Undecided → Low
status: New → Incomplete
Peter Kerekfy (kerekfyp) wrote :

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) wrote :

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) wrote :
Changed in gvfs:
status: Incomplete → Triaged
Changed in gvfs:
status: Unknown → New
Changed in gvfs:
importance: Unknown → High
Odin Hørthe Omdal (velmont) wrote :

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) wrote :

Bug will likely never be solved.

Victor Yap (victor-yap) wrote :

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

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

Changed in gvfs:
status: New → Expired
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.