GNOME Bugzilla – Bug 559065
Samba desktop shares are not accessible after suspend
Last modified: 2021-06-18 15:55:42 UTC
Please describe the problem: I connect to samba share: enter smb://computer/c$ URI in address line in nautilus. It prompts for password, I enter it, the resource is now accessible. Also it puts an icon for this resource on desktop. After suspend this icon is not accessible anymore. But this resource in "bookmarks" pane is accessible well! It confuses user very much. Here is the illustration http://img241.imageshack.us/img241/6750/nautaa1.jpg Text tells me: "For this file type the application is not installed". If I go to Nautilus window, click on samу resource in Bookmarks on the left, THEN the desktop icon is accesible AGAIN! Steps to reproduce: 1. Connect to a samba share using Nautilus. 2. Suspend, wake up. 3. Try to click desktop icon of the resource - you'll get http://img241.imageshack.us/img241/6750/nautaa1.jpg 4. Open Nautilus, click on the same resource in the bookmarks pane. Then close Nautilus 5. Then the desktop icon is accessible again. Actual results: This happens: http://img241.imageshack.us/img241/6750/nautaa1.jpg Expected results: The samba share must open. Does this happen every time? Yes. Other information:
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.