autofs timeout

[Donjan Rodic]

Binary package hint: nautilus

OS: Ubuntu 8.10 Intrepid, upgraded from Hardy
Software: SSHFS, AutoFS, no changes concerning Nautilus

I'm using SSHFS with AutoFS to mount remote shares, which I must have unmounted after some time because of security concerns. This has had me set a timeout on the AutoFS mounts.

The problem is that when opening a remote folder in Nautilus, the timeout countdown starts as soon as I stop clicking on folders/files. When it's down, I get a password prompt.
This is buggy behaviour to me, because if I set the timeout to 10 seconds, there is a password prompt every 10 seconds if I just have a remote folder open in Nautilus, doing nothing else. Of course I've got a bigger timeout, but it's still quite annoying.

I think that it should either:
1. Start the timeout as soon as I don't browse around or poll the file system manually in any other way. Then ask for a password only if user interaction occurs.

2. Don't time out as long as I have an open remote folder (after closing the last remote directory, let AutoFS time out and unmount). This is how KDE's Konqueror and gnome-terminal behave.

There is already a bug filed at the GNOME bugzilla about this. But it originates from 2002 and the last comment is from 2006... which is about the issue still not being resolved.
That's why I'm reporting here. If anyone has a better idea who to harass into fixing this, speak up ;)
Here's the GNOME bug:
http://bugzilla.gnome.org/show_bug.cgi?id=101673

I've also started a thread at the ubuntuforums.org:
http://ubuntuforums.org/showthread.php?t=1003656

[Dmills-b (dmills-b)]

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).

[Alexander Larsson (alexl-redhat)]

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.

[Alexander Larsson (alexl-redhat)]

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

[Kjartan Maraas (kmaraas)]

Is this still a problem with 2.2 or newer?

[Kjartan Maraas (kmaraas)]

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

[Matthew Gatto (mattgatto)]

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

[Matthew Gatto (mattgatto)]

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

[Matthew Gatto (mattgatto)]

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

[Bugmaster-3 (bugmaster-3)]

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

[Gbdavey (gbdavey)]

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.

[Christian Neumair (chris-gnome-de)]

Is this still an issue with Nautilus 2.12/2.13?

[Gnome-bugzilla (gnome-bugzilla)]

(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.

[Pedro Villavicencio (pedro)]

probably not an easy issue to fix and creating a bug in launchpad only create extra work for the developers and triagers who read these and have thousand of extra bugs to deal with daily, so please keep that in mind.

[Donjan Rodic (bryonak)]

I know that, and I try not to report redundant bugs or intended features...
Just helping to improve Ubuntu.

I prefer Launchpad over Bugzilla (don't even have a login at the Gnome tracker) and I think that this Nautilus issue is an error that has got too little attention and needs fixing. Hence reporting it here.

[Donjan Rodic (bryonak)]

It's become much worse with Jaunty :\

Now clicking on any (local or remote) folder anywhere (Desktop, home) makes Nautilus try to mount the remote SSHFS folder (gives me a password prompt). I haven't set any bookmarks.

If I open Thunar or browse my local file system in bash, everything's fine... that is, no remote folders get mounted.
When I browse the SSHFS test folder in Thunar or bash, they ask for a password once and then both keep the mount alive as long as I'm idling in a remote folder.
After leaving all remote folders the countdown set's in and unmounts... which is what Nautilus ideally should be doing as well, instead of having the countdown start as soon as I'm done opening a new remote folder. But this is a minor problem to the one mentioned above.

My current /etc/auto.master:
/media/SSHFS /etc/auto.sshfs --timeout=10,--ghost

My current /etc/auto.sshfs:
TEST -fstype=fuse,rw :sshfs\#USER@DOMAIN\:/

I've tried juggling around options like setting the uid/gid in auto.master or setting noatime,noemtpy and similar in aut.sshfs.

SSHFS works perfectly when mounting manually (via launcher scripts), which is what I've been doing all the time now.
AutoFS also works as intended, mounting/unmounting cleanly in Thunar and bash.
I'd really like to have the "seamless" file system experience in Nautilus... except for the password of course, but that's a necessary additional security step for me, and working around it by turning off password auth only fights the symptoms.
But

[Donjan Rodic (bryonak)]

It's become much worse with Jaunty :\

Now clicking on any (local or remote) folder anywhere (Desktop, home) makes Nautilus try to mount the remote SSHFS folder (gives me a password prompt). I haven't set any bookmarks.

If I open Thunar or browse my local file system in bash, everything's fine... that is, no remote folders get mounted.
When I browse the SSHFS test folder in Thunar or bash, they ask for a password once and then both keep the mount alive as long as I'm idling in a remote folder.
After leaving all remote folders the countdown set's in and unmounts... which is what Nautilus ideally should be doing as well, instead of having the countdown start as soon as I'm done opening a new remote folder. But this is a minor problem to the one mentioned above.

My current /etc/auto.master:
/media/SSHFS /etc/auto.sshfs --timeout=10,--ghost

My current /etc/auto.sshfs:
TEST -fstype=fuse,rw :sshfs\#USER@DOMAIN\:/

I've tried juggling around options like setting the uid/gid in auto.master or setting noatime,noemtpy and similar in aut.sshfs.

SSHFS works perfectly when mounting manually (via launcher scripts), which is what I've been doing all the time now.
AutoFS also works as intended, mounting/unmounting cleanly in Thunar and bash.
I'd really like to have the "seamless" file system experience in Nautilus... except for the password of course, but that's a necessary additional security step for me, and working around it by turning off password auth only figh§ts the symptoms.

[Donjan Rodic (bryonak)]

Sorry for the double post (now triple -.-)), slow connection over here

[Donjan Rodic (bryonak)]

Still not better with Karmic, exactly the same Nautilus behaviour as with Jaunty.

[Matthew-thyer (matthew-thyer)]

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.

[Gnomebugzilla (gnomebugzilla)]

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

[Matthew-thyer (matthew-thyer)]

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 ?

[Gnomebugzilla (gnomebugzilla)]

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...)

[Gnomebugzilla (gnomebugzilla)]

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

[Andre Klapper (a9016009)]

Retesting with 2.32 or 3.0 very welcome.

[Andre Klapper (a9016009)]

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?

[Matthew-thyer (matthew-thyer)]

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).

[Simon-gerhards (simon-gerhards)]

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

[Andre Klapper (a9016009)]

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

[Simon-gerhards (simon-gerhards)]

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.

[Donjan Rodic (bryonak)]

The bug still persists as of 12.10.

[Andreas Bartels (andreas-bartels)]

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.

[Andreas Bartels (andreas-bartels)]

Forgot to tell I am using new Ubuntu 14.04 LTS

[7-chad (7-chad)]

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.

[Dark Dragon (darkdragon-001)]

Not yet migrated to gitlab.

[Dark Dragon (darkdragon-001)]

I don't know how I can additionally link the following bug report in GNOME Gitlab:
https://gitlab.gnome.org/GNOME/nautilus/-/issues/1514

[Andre Klapper (a9016009)]

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.