autofs timeout

Bug #306673 reported by Donjan Rodic on 2008-12-09
30
This bug affects 6 people
Affects Status Importance Assigned to Milestone
Nautilus
Confirmed
High
nautilus (Ubuntu)
Low
Ubuntu Desktop Bugs

Bug Description

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

Pedro Villavicencio (pedro) wrote :

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.

Changed in nautilus:
assignee: nobody → desktop-bugs
importance: Undecided → Low
status: New → Triaged
Changed in nautilus:
status: Unknown → Confirmed
Donjan Rodic (bryonak) wrote :

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) wrote :

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) wrote :

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) wrote :

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

Donjan Rodic (bryonak) wrote :

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

Changed in nautilus:
importance: Unknown → High
Changed in nautilus:
status: Confirmed → Incomplete
Donjan Rodic (bryonak) wrote :

The bug still persists as of 12.10.

Changed in nautilus:
status: Incomplete → Confirmed
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.