Bug Description

Binary package hint: nautilus

I am using ubuntu 7.10, Gutsy 386 version.

I am using a laptop which I use to in home and office. At home I am having network drive which mounted through nfs in home.

I normally put my laptop to suspend and then bring over the same to work. When I access nautilus in this case, it just simply hangs it does not open any folder neither from Places or directly typing command nautilus.

This is very annoying as I have to reboot the computer just for nautilus hanging.

We are closing this bug report because it lacks the information we need to investigate the problem, as described in the previous comments. Please reopen it if you can give us the missing information, and don't hesitate to submit bug reports in the future. To reopen the bug report you can click on the current status, under the Status column, and change the Status back to "New". Thanks again!.

I am still getting this error and it is forcing me to shutdown my ubuntu every day. I have found that issue is probably in gnome-mount extension. Nautilus simply hangs and it does not do anything after printing line

configure an nfs server and client according to this howtohttp://www.ubuntuforums.org/showthread.php?t=249889
configure the client to connect to the nfs server on boot with the mount in /media/mount-point.
disconnect the nfs server from the network.
on the client, open /media/mount-point in nautilus.

nautilus hangs and takes the desktop with it. restarting x does not solve the problem. open windows are responsive and usable. terminal takes input, but the only way to restore the desktop is to reboot.

this problem does NOT appear to be a nautilus bug, as the same thing happens to xubuntu's thunar.

i have tested in kde. konqueror wheel keeps rotating, but it does not hang konqueror. i can go to other folder. but the same does not happen in gnome. desktop hangs and so does nautilus. kde has its own separate application for desktop i think it is kdesktop and hence it does not hang the desktop.

I am seeing this problem with the updated nfs-common package in Hardy. As shown below, I get about a 38 second hang when attempting to mount an export from an off-line server. The same thing on Gutsy produces a "No route to host" message and returns in about 3 seconds.

Same problem here: Under Hardy, when turning off my home network server (running the Hardy server edition), autofs-mounted shares will stall nautilus. The last few lines of an "strace nautilus --no-desktop" read:

The final "poll(" will seemingly hang forever. The mount points are bookmarked in nautilus, and doing the same under a diffferent user who has *not* bookmarked the NFS shares (e.g. as root) will bring up nautilus instantly. This leads to the conclusion that it might be a nautilus bug.

This is not a nautilus bug. I have the same problem in Hardy XUBUNTU which uses Thunar rather than Nautilus. But, it does use the gvfs as far as I know. Whereas, KUBUNTU does not make use of gvfs and is not afflicted with this problem.

After some testing I can confirm that my nautilus stalling issue is related to bookmarking NFS/autofs-mounted shares.
After manually removing those bookmarks from ~/.gtk-bookmarks, nautilus starts up immediately.

Doing some tests with "strace nautilus --no-desktop" reveals that nautilus issues numerous access()-calls to each bookmarked folder, yielding ENOENT for those NFS/autofs-shares after a timeout of some seconds for each call. Since nautilus does *lots* of those calls even before showing its initial window, startup takes endlessly in this case.

Interestingly, these access() calls appear only for the first instance of nautilus, any subsequently started nautilus instances already "know", that those folders are not available (probably via CORBA/orbit?), they don't even load ~/.gtk-bookmarks.

This problem has been going on for awhile. Probably as long as NFS has been around. Here's a thread from 2003: http://markmail.org/message/sxxoq6jbylipwuju
I don't think this will ever be "fixed". it's not a bug, just a design flaw.

> Actually, I think this bug is related to problem with mount.nfs trying
> to mount an export on a non-existent server. See
> https://bugs.launchpad.net/ubuntu/+source/nfs-utils/+bug/234480.
>
> This problem has appeared in Ubuntu Hardy but not in Gutsy.
>
> By the way, I don't see why a design flaw couldn't be a bug. (I think
> Microsoft would call a design flaw a "feature") :-)
>
> --
> nautilus hangs when mounted nfs drive is no longer accessible
> https://bugs.launchpad.net/bugs/164120
> You received this bug notification because you are a direct subscriber
> of the bug.
>

I also have the same problem, folks, Ubuntu Hardy, fully upgraded. When I don't have the NFS in my network, because I move away from that network, then, when I start Gnome, it hangs very quickly.

I have manually deleted NFS directory (which is mounted with autofs) from .gtk-bookmarks, everything goes fine now. If I try to examine that directory from Nautilus, I have to wait, but I'm able to stop it.

I have observed that the problem is that things occur at the background, with no other choice for the user but to wait until autofs tells the user that it is impossible to mount the NFS volume. This thing, apparently, never happens. And so, this task should just be threaded at the background, thus allowing Gnome-mounter (or the application which accesses that directory) continue with the job without interrupting all the system.

It's definitely not a flaw in NFS, since it is not possible to tell that the server is down, except if you wait for a long amount of time, which is not acceptable in this case. The only solution is to do this task asynchronously from within Gnome itself, as KDE obviously does.

Maybe some versions of NFS and autofs wait for a bit shorter doing this task, but this may be wrong in other situations, and anyways, you still have to wait that period of time, which is clearly not the correct thing.

The hang problems are not related to a particular program. Indeed they are observed on all programs that try to access a nfs server which is down. I can confirm that the following programs hang:
* nautilus
* firefox (through FireFTP extension)
* Filezilla

I think the title and the description of this bug report should be reformulated

I believe this is expected NFS behavior, and can be fixed by specifying a soft mount. Hard mount is default due to possible instability issues with soft mounting. Using the soft option fixes the problem for me on all of my machines from Hardy to Jaunty (Ubuntu, Xubuntu, and Kubuntu). The file system remains responsive (though slow) even after the server is disconnected, and a simple "sudo umount /mountpoint" returns the file system to a normal state. For more information, see man nfs "soft / hard".

> I believe this is expected NFS behavior, and can be fixed by specifying
> a soft mount. Hard mount is default due to possible instability issues
> with soft mounting. Using the soft option fixes the problem for me on
> all of my machines from Hardy to Jaunty (Ubuntu, Xubuntu, and Kubuntu).
> The file system remains responsive (though slow) even after the server
> is disconnected, and a simple "sudo umount /mountpoint" returns the file
> system to a normal state. For more information, see man nfs "soft /
> hard".
>
> --
> nautilus hangs when mounted nfs drive is no longer accessible
> https://bugs.launchpad.net/bugs/164120
> You received this bug notification because you are a direct subscriber
> of the bug.
>

I have just retested. I am positive that adding "soft" to the /etc/fstab mount options fixes this problem. Nautilus DOES hang, but only for a minute until NFS times out. Then you get an I/O error and Nautilus starts working as expected again. In the mean time, everything else works perfectly fine, the desktop is not lost, and the rest of the system remains responsive. I have tried this solution with Nautilus, Thunar, and ROX.

I can confirm this behavior on my notebook with ubuntu 9.04, and my old stationary P3 with ubuntu 8.04.2. The problems occured in the last week(s).
Workaround:
Killing "bonobo-activation-server" seems to fix the problem temporarily.

So..... I still get this bug... In 9.10 and 10.04 (also with soft mount).
Should I open this bug or create a new one, as I get the idea people here keep closing it (could be wrong).

I have been chatting with the nfs folks for a while:http://thread.gmane.org/gmane.linux.nfs/30482
We did not solve this bugger yet, I somewhat get the idea that this is not caused by either nautilus or nfs (as it is stateless).

Anyhow, current state is that the performance/health of client machines are totally dependent of a single server machine (even if the server is serving non-trivial files to a non-trivial client-directory).

I have upgraded to latest ubuntu 9.04. Now all my file browsers hangs (nautilus, dolphin, konqueror) when nfs server is not available. As I have stated when I logged the bug, nfs when disconnected hangs everything.

Interestingly though running the script umountnfs.sh in /etc/init.d resolves the problem, which means unmounting solves the problem. I do not know who has to fix this as a user I feel it is ubuntu bug.

If you feel it is not nfs issue, please include the package which you think is the issue.

I do not think nautilus, konqueror or dolphin are the issue as problem would not occur in all three when nfs mount i not available.

@Steve Langasek:
Nautilus is hanging or not even starting at all, totem and vlc are stuttering at set intervals when playing video files stored on local disk, even the terminal is unresponsive at times, when I lock the screen I have to wait two minutes after entering my password before I get to my desktop again... All of this with a soft mount (from disconnected nfs server) onto a directory I haven't even accessed in that session.
This is not comparable with something being "slow", I was referring to the title of the bug "Nautilus hangs.....etc."

I do not think it is related to nautilus. I have tried dolphin, konqueror and even thunar. All of them behave in consistent manner. They do not respond, give blank screen till they are killed or terminated. If it were related to nautilus libraries don't you think it would have disappeared in dolphin, thunar, konqueror. Unless they are relying on some common place.

As I said earlier they would start behaving normally as soon as umountnfs.sh is run from /etc/init.d. So, I feel there is a problem in which nfs mount is behaving. Hence I feel it is related to nfs and not nautilus.

As per your explanation, nfs being slow is not related to the nfs-util. Either nfs time out is not set properly.

I still feel it is related to nfs-util. I would like you to reconsider the explanation I gave above. If you still feel it is not related to nfs-util. Kindly please close the issue. I would open bugs on thunar, dolphin and konqueror too.

I am using a laptop which I use to in home and office. At home I am having network drive which mounted through nfs in home.

I normally put my laptop to suspend and then bring over the same to work. When I access dolphin in this case, it just simply hangs it does not open any folder neither from quickview or folder view. Even plasma-desktop hangs. the only option is to reboot even terminating the app does not work.

This is very annoying as I have to reboot the computer just for dolphin hanging.

This is similar to bug I created for nautilus too here in ubuntu bug tracker.

I agree that it is not very likely that this problem lies in nfs, but I also don't think it lies in nautilus, thunar, dolphin etc. I am also experiencing hangs in vlc, totem, terminal even the login screen (after I locked the screen). Basically any application that requires (additional) disk access (which is just about every application) has issues when nfs server is disconnected. It could be that file managers are behaving especially bad as they read entire directories (or even directory structures), not just a single file.
I tend to think it has something to do with the mounting process itself or with vfs, but I have not been able to find concrete evidence.

I have nfs soft mounted to /remote/nfsshare, I shut down the nfs server. Now when I try to launch "Places-->Home Folder" nothing happens accept the cursor is in hour glass mode for some time.
So I tried to launch it from the terminal and got this:
whoop@whoop-desktop:~$ nautilus /home/whoop/

(nautilus:2039): Unique-DBus-WARNING **: Error while sending message: 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.

(nautilus:2039): Unique-DBus-WARNING **: Error while sending message: 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.
whoop@whoop-desktop:~$

In Ubuntu 12.04, after installing autofs and setting up nfs autofs mounts, my nautilus temporarily hangs (window greys, freezes, becomes unresponsive) when navigating local directories, if the server exporting the autofs nfs mounts is offline. This is observed even when navigating local directories that do not contain any of the autofs mount points, i.e. navigating somewhere under /home, with autofs nfs mount points that are somewhere under /var. Although the hang is temporary, it's a looooong temporary. I noticed a previous comment suggesting that using separate threads could fix this problem in nautilus, even if the problem could technically be attributed to nfs or autofs. Sounds sensible.

Seems as if it makes a call to readlink() which returns -1 indicating an error (3rd line to last), then it realizes that it has an error. And, does a readlink in the same fashion setting buffsize to -160, presumably in whatever handles the error.. I'm confused.

Here is the strace, we can see the two calls to readlink which has the actual path.. A simple `ls` in the directory fails /mnt hangs without even running umount. This is what I assume is the core of the nautilus symptom people are ranting about. I think this is also why nfs drives can't umount when disconnected. I don't know why umount has to ls the parent directory to umount the location. I can understand it doing so, but I'd expect it the -f option to just purge the kernel's knowledge of the mount point and move on with life. That `umount -f` issues an readlink() in cwd, and that an ls with failed mount hangs is what I assume is the problem here.
,
fstat(3, {st_mode=S_IFREG|0444, st_size=0, ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f2630b74000
read(3, "nodev\tsysfs\nnodev\trootfs\nnodev\tr"..., 1024) = 365
read(3, "", 1024) = 0
close(3) = 0
munmap(0x7f2630b74000, 4096) = 0
open("/usr/lib/locale/locale-archive", O_RDONLY|O_CLOEXEC) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=2919792, ...}) = 0
mmap(NULL, 2919792, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7f262f610000
close(3) = 0
umask(022) = 022
getuid() = 0
geteuid() = 0
readlink("/mnt", 0x7fff2a645120, 4096) = -1 EINVAL (Invalid argument)
readlink("/mnt/nfs",

This seems to affect several KDE applications as well (ark, ksnapshot).

I have a NAS which is mounted by autofs. If I accidentically power it off before my computer, then opening a file dialog in said applications lets them hang. Output from strace indicates that there's an lstat call which doesn't return: