autofs timeout

Whilst setting up some Linux boxes for normal users (who don't know about
mounting/unmounting...) I noticed that when you try to access an autofs'd
floppy drive from nautilus (1.0.4), the device will mount, but the mount
doesn't hold, it disappears as soon as the timeout (in this case 2
secondes) expires, upon which nautilus throws you back to your home directory.

The problem doesn't arise with supermount (patching the kernel is a viable
workaround).

From what I know about autofs, I'd say that nautilus is lsing the directory
it shows, but isn't cding to it before hand, hence the loss of lock, and
the unmounting.

I'm not too familiar with the nautilus code, so I can't say for sure, but I
think a

sprintf(&buffer,"cd %s",dir);
system(buffer);

in the function that's invoked when you change directory should do the
trick for this one (needs testing though, I can't quite remember if
system() opens a new shell for it's commands, which is closed upon exit, or
whether it goes straight through the applications interfaces. If it's the
former, this fix would not work).

Its a lot easier to call chdir() directly instead of launching a shell
to do it. But that won't help anyway, we can't use cwd to keep the dir
open, since several directories may be open at the same time, not to
mention that it would be a very strange thing to do.

I guess we could have the view hold an open ref to the directory though.

Not to mention what happens when you go to a uri with "; rm -rf /" at
the end...

Is this still a problem with 2.2 or newer?

Just thought I'd make a note that mail to the reporter is bouncing.

<email address hidden>: Name service error for technisys.com.ar:
Hostfound but no data record of requested type

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

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

Changing Summary to reflect new info from dups, adding a URL from one
of the dups, and setting Severity -> Major since it sucks.

The URL field has been removed from bugzilla.gnome.org. This URL was in the old URL field, and is being added as a comment so that the data is not lost. Please email <email address hidden> if you have any questions.

URL:
http://mail.gnome.org/archives/nautilus-list/2004-January/msg00105.html

I just upgraded from 2.4 to 2.6 in hopes of having this bug fixed, but no luck.
 As well as loosing the window on an automounted fs after the timeout, the
computer icon that shows various fs's gives errors when trying to view an fs
that is controlled by automount. It gives an "unable to mount the selected
volume" error with details of:
"mount: <device> already mounted or <mount-point> busy
mount: according to mtab, <device> is already mounted on <mount-point>"

It would be nice to be able to tell nautilus that certain fs's are controlled by
automount and have nautilus work seamlessly with automount.

Is this still an issue with Nautilus 2.12/2.13?

(In reply to comment #10)
> Is this still an issue with Nautilus 2.12/2.13?
>

I have a similar problem with NFS mounts on Fedora FC5, Nautilus 2.14.3

`uname -a` => Linux 2.6.17-1.2174_FC5 #1 SMP Tue Aug 8 15:30:44 EDT 2006 x86_64 x86_64 x86_64 GNU/Linux

If I have a Nautilus window open looking at a subdirectory on the NFS mount, it resets itself back to the users home directory after a few seconds.

If I open a separate command line shell and cd to the mounted directory, then the Nautilus window stays open.

If I close the command line shell, the Nautilus window reverts back to the users home directory after a few seconds.

I'm happy to help with debugging/testing if you tell me what information you need.

----

I don't see the same problem with Fedora FC4, Nautilus 2.10.0.

However, this version seems to poll the NFS mount to keep it alive, swamping the network with NFS FSSTAT calls several times a second.

This is still a problem with Nautilus 2.16.2-7 on CentOS 5.5 x86_64.
This is a major problem that is putting off customers.

I have reproduced the problem by logging in and opening a number of folders using Nautilus under /opt/user-data.
After 5 minutes, all Nautilus folder windows that are under /opt/user-data will close.

I have worked around the problem by changing the autofs unmount timeout to 2 days (from 5 minutes) by editing the TIMEOUT variable in "/etc/sysconfig/autofs".

Detailed configuration information:

$ rpm -qa | egrep autofs\|kernel\|nautilus | sort
autofs-5.0.1-0.rc2.143.el5.x86_64
kernel-2.6.18-194.3.1.el5.x86_64
kernel-2.6.18-194.el5.x86_64
nautilus-2.16.2-7.el5.x86_64
nautilus-cd-burner-2.16.0-7.el5.i386
nautilus-cd-burner-2.16.0-7.el5.x86_64
nautilus-extensions-2.16.2-7.el5.i386
nautilus-extensions-2.16.2-7.el5.x86_64
nautilus-open-terminal-0.6-7.el5.x86_64
nautilus-sendto-1.0.1-6.el5.centos.x86_64

$ grep ^/- /etc/auto.master
/- /etc/auto.direct

$ cat /etc/auto.direct
/opt/user-data fileserver:/export/org/data/something/something

File server is Solaris 9 with kernel Generic_122300-07.

Is this a problem in a version of nautilus where gvfs is used (like 2.28 (?) or 2.30)?

Marcus,

I have not tested in any other environment as my primary Linux solution is RedHat Enterprise Linux / CentOS and nautilus is version 2.16.2-7 there.

I understand that RedHat will typically back port fixes to significant problems from newer releases if possible so I will test this scenario if you think it would be useful.

To narrow this down, can you give me an idea of a Red Hat distribution version (e.g. Fedora 11 with updates) that would get me to a point of having nautilus where gvfs is used ?

Matthew, I'm not that familiar with Red Hat / Fedora releases but I think the latest version of Fedora (like 13?) should include nautilus 2.30 (latest stable). If you have time and it's possible it might be good to check if the problem is still there. (It probably is as nautilus closes / goes up in directories when the underlaying media is removed/unmounted. But again, nautilus 2.16 is an old version so maybe things have changed. Also other parts of the stack might have changed in a newer version of your distribution of choice that fixes the problem. But I still understand if you'll have to stick with the current Enterprise version...)

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

Retesting with 2.32 or 3.0 very welcome.

The backend for nfs functionality has changed around 2.24 (gnome-vfs ->
gio/gvfs)....

Is this still an issue in a recent Nautilus version, such as 3.0 or 3.2?

I'm really not sure when I can test this again.
I have started a new role and it's no longer that important to me.

Someone else could easily test this.

The test case I could care about is CentOS 6.0 (or 6.1) which I hope will be fixed (as it uses Nautilus 2.28.4).

I can verify that this problem still exists in Nautilus 3.6.1.

Simon: Could you provide your steps to reproduce please / more information about your setup?

I run Debian unstable with Gnome 3.6 components from experimental.

I have mounted a NFS4 share via autofs5. The timeout is set to 10 seconds. When I access the folder with Nautilus autofs mounts the share. After 10 seconds of doing nothing but having this folder opened in Nautilus autofs unmounts the share and Nautilus goes back to the parent directory.

This behaviour is caused because it is possible to unmount directories that are opened in Nautilus. You can test this with these steps:
* #mount -o bind /tmp /mnt
* Open /mnt with Nautilus
* #umount /mnt
The umount succeeds despite Nautilus displaying the folder. In this case however Nautilus does not even notice the unmount and does not go one folder up.

I've same feature but use sshfs with autofs.

The very difference is nautilus is not keeping open the directory that it is watching at and but thats the major fault, if the drive gets unmounted it is not trying to get the directory again. Its only falling back to the mountpoint.

So I think there are 4 ways ob solving this problem.

a.
  keep the directory open that lsof will find a reportable connection to the drive and because of it autofs won't unmount.

b.
  check how does nautilus gets informed about the unmount. If this is done by autofs or the kernel, tell the guys of autofs, to use this function as well for sensoring used disks.

c.
  touch all the time you are in a directory this in between x seconds so that there will be all x seconds a use of this directory and do not use timouts for autofs shorter than x+1 seconds to make sure that autofs doesn't cansel the connection at all if a directory is opened by nautilus

d.
  do not set nautilus back to the mountpoint until nautilus hasn't tried to connect the drive twice if someone does any operation to the window. Because it is not nessesary to tell the unmount before not anybody tries to use the actual directory. If no connection is possible to the drive - automount doesn't reconnect - react as it was before but this won't be a problem, as than there is no way to access or read the directory at all and it is wright to jump back to the first possible point - the mountpoint.

I don't know how nautilus is doing it but I know that lsof doesn't tells anythin open and that nautilus is than by reading a dir opening lots of files short - maybe to get previews on them, but after them it is closing all open connections. (Think this isn't bad. as long as you do not reset the possition of noutilus without trying to connect the unmounted directory again if someone like to do something to it or its content) Best only react if someone tries to do something to the one item of the directory or the directory it self. If he does try to reread it and if that isn't possible jump back. This means nautilus isn't reacting in that moment while a drive is unmouted by changing its shown directory eaven if it might show the change in the sidebar.

Forgot to tell I am using new Ubuntu 14.04 LTS

This affects me too. Using Fedora 24 with nautilus-3.20.1-1.fc24.x86_64.rpm.

The problematic mountpoint in fstab is:

    daisy.local:/ /net/daisy nfs noauto,tcp,x-systemd.automount,x-systemd.idle-timeout=4s 0 0

Nautilus's debug logs reveal that this code is hit immediately before Nautilus
changes to the parent directory:

    # file: nautilus-bookmark.c
    # gitweb: https://git.gnome.org/browse/nautilus/tree/libnautilus-private/nautilus-bookmark.c?h=3.20.0#n118
    static void
    bookmark_file_changed_callback (NautilusFile *file,
                                    NautilusBookmark *bookmark)
    {
        ...
        if (nautilus_file_is_gone (file) ||
            nautilus_file_is_in_trash (file)) {
            /* The file we were monitoring has been trashed, deleted,
             * or moved in a way that we didn't notice. We should make
             * a spanking new NautilusFile object for this
             * location so if a new file appears in this place
             * we will notice. However, we can't immediately do so
             * because creating a new NautilusFile directly as a result
             * of noticing a file goes away may trigger i/o on that file
             * again, noticeing it is gone, leading to a loop.
             * So, the new NautilusFile is created when the bookmark
             * is used again. However, this is not really a problem, as
             * we don't want to change the icon or anything about the
             * bookmark just because its not there anymore.
             */
            DEBUG ("%s: trashed", nautilus_bookmark_get_name (bookmark));
            nautilus_bookmark_disconnect_file (bookmark);
        } else {
        ...

I assume that G_FILE_MONITOR_EVENT_UNMOUNTED indirectly triggers this callback.

As a workaround, I simply removed the 'x-systemd.idle-timeout' option from fstab.

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
which have not seen updates for a longer time (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.