GNOME Bugzilla – Bug 397441
Nautilus kills sshfs daemon when mount.fuse returns
Last modified: 2010-09-16 12:51:50 UTC
Please describe the problem: I put the following entry in /etc/fstab: sshfs#user@host:/ /media/mount fuse user,noauto 0 0 Then nautilus notices it and the "filesystem" appears in computer:// When I double-click on it, I get into /media/mount, but nothing is mounted. To find what was happening, I modified the /sbin/mount.fuse script to sleep 10 seconds at the end, and then I saw that the sshfs is mounted (and if another nautilus windows is located at /media/mount, nautilus shows the correct contents), until the sleep is over then when mount returns sshfs is killed (I think it's by nautilus, who else ?) and nautilus changes the location from /media/mount to the home folder (which is a feature since it reacts to the effective unmount) Steps to reproduce: 1. Put the above line in fstab 2. Add "sleep 10" at the end of /sbin/mount.fuse 3. Go to computer:// and double-click on the proper icon Actual results: The mount is done, and I can see the correct contents in nautilus for 10 seconds (I used a local ssh so everything is fast); then when mount exits the sshfs process disappears and the file system is unmounted, nautilus notices it and jumps to home. Expected results: sshfs continues to live happily ever after and I can browse what I want, at least until I decide to unmount. Does this happen every time? Yes. Other information: Note that when doing a CLI mount (or pmount) everything works as expected. I haven't enough expertise in nautilus/gnome-vfs to know if it's gnome-vfs or nautilus the culprit. Also note that if I change the line calling sshfs to have a "screen -d -m" at the beginning, sshfs isn't killed (I needed to keep a small sleep to ensure screen had time to fork). So it's a workaround, but not an easy one (for non skilled people). I thus think nautilus kills the processes (it also kills a "sleep 100 &") affiliated to the mount process, even if they are not anymore child processes (at least as reported by pstree). Maybe screen works harder than sshfs to ensure its inner screen process gets saved and reparented to init.
As a (still ugly) workaround, it is sufficient to put #!/bin/sh screen -d -m /usr/bin/sshfs -f "$@" sleep 1 into /usr/local/bin/sshfs, with the right permissions.
Do you still have this problem in an up to date version of nautilus (such as 2.30) as a lot have happened since 2.14... ?
Closing this bug report as no further information has been provided. Please feel free to reopen this bug if you can provide the information asked for. Thanks!