Ubuntu 9.10 / Nautilus 2.28.1.

Going into suspend using pm-suspend doesn't work while a share is connected via Nautilus.

Going into suspend using uswsusp works fine, the share also works fine after resuming, as long as the network is back and kept the same IP.

If the IP changed it takes Gnome ages to notice that the share is no longer working, if at all. Usually at some point it hangs up and I have to kill the session to get it working again.

*** Bug 605141 has been marked as a duplicate of this bug. ***

I just want to confirm that this bug is indeed real. It is the single reason my wife will not let me install ubuntu on her laptop to replace XP. We both use a samba server for all of our documents and being laptop users, the suspend kills our smb connections. It is a pain.

This is still true for Nautilus 2.32.2.1 (on Ubuntu natty). Sad, that ressources are put into redesigning the desktop each and every cycle, new regressions (gvfs to gio) are introduced, but nobody cares to fix them.

[Bumping version number as per comment 4]

Thanks André, I wanted to add that this is not a suspend issue, but a "simple" timeout/connection issue - The bookmarks must have some re-connect logic in the exec path, whereas the simple desktop links are missing. I will praise the day, when this one is fixed :)

Hi André,
this also happens in Nautilus 3.2.1 (Ubuntu Oneiric). Any chance, that a developer will look into this issue?

This is still valid in Nautilus 3.4.2. Any work done on this so far?

Greetings from Ubuntu bug tracker and year 2017. The issue is still happening and is also related to sftp and probably all other gvfs protocols. 

https://bugs.launchpad.net/ubuntu/+source/gvfs/+bug/1366840

This Nemo bug is probably related https://github.com/linuxmint/nemo/issues/678

IMO this should have quite high priority, as it can lead to user data loss. The reason and solution are quite well understood.

(In reply to ville.ranki from comment #9)
> Greetings from Ubuntu bug tracker and year 2017. The issue is still
> happening and is also related to sftp and probably all other gvfs protocols. 
> 
> https://bugs.launchpad.net/ubuntu/+source/gvfs/+bug/1366840
> 
> This Nemo bug is probably related
> https://github.com/linuxmint/nemo/issues/678
> 
> IMO this should have quite high priority, as it can lead to user data loss.
> The reason and solution are quite well understood.

Greetings,

Could you explain the solution from Nautilus side that can be done?

Nautilus should use some method to check if the mounts are still accessible after network has been reconnected (after suspend and other situations). 
I don't know if there is a common method in gvfs APIs to do that. 

If not, nautilus could update directory listing in each mount with low timeout (10 secs or so) and if it fails, assume the mount is not accessible anymore.

Nautilus should then remount the unaccessible mounts.

Preferably some of this functionality should be done in gvfs and/or it's backends so that other applications benefit from it. There may be cases where user wants direct control of mounting and unmounting so this kind of automation can't be enabled by default.

Well, in any case Nautilus should not freeze the system when a mount is not accessible anymore. In the meantime I use the following script 

#!/bin/bash

sudo killall gvfsd-ftp
sudo killall gvfsd-sftp
sudo killall gvfsd-smb-browse
sudo killall gvfsd-dav
sudo killall gvfsd-http
sudo killall gvfsd-metadata
sudo killall gvfsd-mtp
sudo killall gvfsd-fuse
sudo killall gvfsd-network
sudo killall gvfsd-computer

to recover my system when this happends, but this is really an ugly workaround. 
Whenever I forget to unmount a sftp location and disconnect the network, I always have to switch to a different terminal (Ctrl+F3), login and run the above script to be able to continue my Gnome session. This is really not how it is supposed to be. What is more, I'm suffering from this bug since 2010, always hoping that it will be fixed in a new Gnome release. Sadly, nothing happens...

(In reply to ville.ranki from comment #11)
> Nautilus should use some method to check if the mounts are still accessible
> after network has been reconnected (after suspend and other situations). 
> I don't know if there is a common method in gvfs APIs to do that. 
> 
> If not, nautilus could update directory listing in each mount with low
> timeout (10 secs or so) and if it fails, assume the mount is not accessible
> anymore.
> 
> Nautilus should then remount the unaccessible mounts.
> 
> Preferably some of this functionality should be done in gvfs and/or it's
> backends so that other applications benefit from it. There may be cases
> where user wants direct control of mounting and unmounting so this kind of
> automation can't be enabled by default.

Nautilus shouldn't poke at all to network directly, as you mention this should go under the hood.

(In reply to Carlos Soriano from comment #13)
> 
> Nautilus shouldn't poke at all to network directly, as you mention this
> should go under the hood.

I agree. I think for me the issue is now sort of solved, since I ended up using this script

cd /etc/NetworkManager/dispatcher.d
sudo nano 90-gnomeunfreeze 

#!/bin/bash

case "$2" in
    down|vpn-down)
                echo "Network is down, performing an emergency unmount of all gvfs network devices.";
                /usr/bin/killall -q gvfsd-dav;
                /usr/bin/killall -q gvfsd-ftp;
                /usr/bin/killall -q gvfsd-sftp;
                /usr/bin/killall -q gvfsd-http;
                /usr/bin/killall -q gvfsd-network;
                /usr/bin/killall -q gvfsd-smb;
                /usr/bin/killall -q gvfsd-smb-browse;
                echo "Emergency unmount done." || :
                ;;
esac 

chmod +x 90-gnomeunfreeze
sudo systemctl restart NetworkManager-dispatcher.service 

Once my ethernet or WiFi connection is down, Network Manager calls my script that prevents existing network shares from freezing the Gnome shell. Initially I tried to use

#!/bin/bash

case "$2" in
	down|vpn-down)
                echo "Network is down, performing an emergency unmount of all gvfs network devices.";
                gvfs-mount -f --unmount-scheme=sftp;
                gvfs-mount -f --unmount-scheme=ftp;
                gvfs-mount -f --unmount-scheme=dav;
                gvfs-mount -f --unmount-scheme=smb;
                echo "Emergency unmount done." || :
                ;;
esac

but this didn't work as for some reason gvfs-mount does not see user mounts when called from root (I also tried various sudo and su combinations to no avail).

Do you think it would be more appropriate to file a bug against gvfs regarding the present behavior? In principle, gvfs would just need to perform an emergency unmount once a share becomes unavailable. This is already possible via the -f and --unmount-scheme keys, so it should not be too difficult to implement (I guess).

GNOME is going to shut down bugzilla.gnome.org in favor of gitlab.gnome.org.
As part of that, we are mass-closing older open tickets in bugzilla.gnome.org (resources are unfortunately quite limited so not every ticket can get handled).

If you can still reproduce the situation described in this ticket in a recent
and supported software version of Files (nautilus), then please follow
  https://wiki.gnome.org/GettingInTouch/BugReportingGuidelines
and create a new ticket at
  https://gitlab.gnome.org/GNOME/nautilus/-/issues/

Thank you for your understanding and your help.