In hardy heron, a fuse based sshfs mount that is mounted through /etc/fstab does NOT match its corresponding entry in /etc/mtab.
I am filing this as a bug, because it breaks a number of standard ubuntu/gnome/debian/linux utilities, including umount and the unmount capability of the "Disk Mounter" applet.
For example, this line in /etc/fstab:
sshfs#username@ubuntusshserver:/home/username /home/username/mnt/sshfs/ubuntusshserver/username fuse comment=sshfs,users,exec,nodev,nosuid,rw,nosuid,noauto,uid=1000,gid=1000,allow_other,reconnect,transform_symlinks,port=22,BatchMode=yes 0 0
results in this line in /etc/mtab (when this mount point is mounted):
username@ubuntusshserver:/home/username /home/username/mnt/sshfs/ubuntusshserver/username fuse.sshfs rw,nosuid,nodev,max_read=65536,allow_other,user=username 0 0
The line mentioned for /etc/fstab allows me to easily mount the sshfs mount point from mount or the "Disk Mounter" applet with no problems, but breaks umount and "Disk Mounter" for unmounting. "fusermount -u" or "fusermount -u -z" still work.
Running the following line to use sed to edit /etc/mtab to correct the problem after a mount results in desired behavior, and verifies that this problem is a bug:
sudo sed 's/\(^[^@]\{1,\}@\)\(.\{1,\}\) fuse\.sshfs /sshfs#\1\2 fuse /' -i /etc/mtab
This line is, of course, a workaround for the bug, and requires su privileges to run, so it is NOT a solution.
The source package for this bug should be sshfs-fuse 1.9-1. The binary package is sshfs. I believe that this behavior did not exist in fiesty fawn, and cannot tell you if it existed in gutsy gibbon. I am almost sure that this is new to hardy heron, so it is probably a design change that resulted in some bugs. I also believe that this bug is the true cause of bug#152978 (see https://bugs.launchpad.net/ubuntu/+source/tomboy/+bug/152978/comments/11)
Here are the results from 'lsb_release -rd':
Description: Ubuntu 8.04
Release: 8.04
Here are the results from 'apt-cache policy sshfs':
apt-cache policy sshfs
sshfs:
Installed: 1.9-1
Candidate: 1.9-1
Version table:
*** 1.9-1 0
500 http://archive.ubuntu.com hardy/universe Packages
100 /var/lib/dpkg/status
Here is my kernel from 'uname -a':
Linux ubuntu 2.6.24-19-generic #1 SMP Wed Jun 18 14:15:37 UTC 2008 x86_64 GNU/Linux
WORKAROUND to mount using /etc/fstab:
sshfs#<email address hidden>:/home/user /mnt/sshdisk fuse user,noauto,fsname=sshfs#<email address hidden>:/home/user 0 0
(this is supposed to be one line in fstab)
Here is a workaround which I believe is Ubuntu and Debian compliant. It requires sed, inotify-tools, and upstart (current versions of Ubuntu use upstart instead if initd):
Step 0) Prep:
sudo apt-get install inotify-tools (sed and upstart are standard parts of Ubuntu now)
Step 1) Create an upstart job which will run and respawn whenever the system is running (the criteria are identical to the current tty* jobs). Please note that upstart jobs are NOT shell scripts. Please do not include a shebang, or set the executable bits on them.
(As the su) I created a file called /etc/event.
# sshfsmountfix - FUSE based sshfs mounting fix
#
# This service maintains a getty on monitors the /etc/mtab
# file from the point the system is started until it is shut
# down again. It runs a small sed script to change entries
# with fuse.sshfs as their "type" so that they can be
# correctly unmounted by the same user that mouned them
# with umount or applications that call umount (otherwise,
# fusermount -u [-z] is required)
start on runlevel 2
start on runlevel 3
stop on runlevel 0
stop on runlevel 1
stop on runlevel 4
stop on runlevel 5
stop on runlevel 6
respawn
exec /usr/local/
Step 2) Create the script that this job execs and respawns as needed. Please note every time inotify observes a MODIFY event for /etc/mtab, this script will execute sed on /etc/mtab (in-place), and this script will then exit!!! Yes, it will exit. Do not fear. Since this script is called by the upstart job above, it will automatically respawn as long as the runlevel is 2 or 3 (or if it changes to 2 or 3). Upstart jobs are cool. :)
(As the su), I created a file called /usr/local/
#!/bin/sh
while inotifywait -e modify /etc/mtab; do
/bin/sed 's/\(^[
done
Step 3) Set the permissions and ownership for /usr/local/
sudo chown root.root /usr/local/
chmod 700 /usr/local/
Step 4) Manually start the new upstart sshfsmountfix job (you can verify that the job exists and is stopped with "sudo initctl list":
sudo initctl start sshfsmountfix
Note that this fix is ONLY a workaround. It does not fix the bug that caused this condition to occur. It also does NOT make changes to what is seen by /proc/mounts or /proc/self/mounts, or any programs that depend on /proc/mounts or /proc/self/mounts.
However, this workaround is nice in that it only has to be installed by a su once, and it should "automagically" fix any sshfs entries in /etc/mtab. It of course, is completely reliant on inotify (not officially supported by Ubuntu) and upstart (officially supported by Ubuntu). In all fairness, sshfs is not officially supported by Ubuntu either, so this doesn't really change your support status.
High-level overview: An upstart job called sshfsmountfix is started and respawned as needed on runlevels 2 and 3, and stopped for all other runlevels. This job, when running, keeps a copy of /usr/local/