sshfs /etc/mtab and /etc/fstab do not match, umount and unmount through "Disk Mounter" applet / Nautilus do not work

Bug #243298 reported by Chuck Renner on 2008-06-26
144
This bug affects 25 people
Affects Status Importance Assigned to Milestone
One Hundred Papercuts
Undecided
Unassigned
sshfs-fuse (Ubuntu)
Undecided
MOTU
Nominated for Intrepid by Earth
Nominated for Karmic by keredson
Nominated for Lucid by keredson

Bug Description

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)

Related branches

description: updated
Changed in sshfs-fuse:
assignee: nobody → motu
Chuck Renner (chuckrenner) wrote :
Download full text (4.1 KiB)

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.d/sshfsmountfix, with the following contents:
# 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/bin/mtab-monitor

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/mtab-monitor with the following contents:
#!/bin/sh
while inotifywait -e modify /etc/mtab; do
 /bin/sed 's/\(^[^@]\{1,\}@\)\(.\{1,\}\) fuse\.sshfs /sshfs#\1\2 fuse /' -i /etc/mtab
done

Step 3) Set the permissions and ownership for /usr/local/bin/mtab-monitor
sudo chown root.root /usr/local/bin/mtab-monitor
chmod 700 /usr/local/bin/mtab-monitor

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/bin/mtab-monitor running at all times. /usr/local/bin/mtab-monitor runs inotifywait...

Read more...

Nick B. (futurepilot) wrote :

I can confirm this. Adding an SSHFS mount to fstab works fine but when you try to unmount it by right clicking on the disk on the desktop and selecting Unmount Volume it gives an error that "mount disagrees with fstab"

Christian Gut (cycloon) wrote :

Same here.

Chuck Renner (chuckrenner) wrote :

Two other people found the same behavior. Sounds "confirmed" to me.

Changed in sshfs-fuse:
status: New → Confirmed
gervin23 (gervin23) wrote :

Confirmed here too except I'm running Intrepid.

damian (me-arcsin) wrote :

In fuse-2.7.4/util/fusermount.c swap lines 486-494 with lines 498-505 and recompile.

Øyvind Jensen (jegerjensen) wrote :

I had the same problem, but now it works with the option in fstab

fsname=sshfs#<email address hidden>/home/user

More details in the post http://article.gmane.org/gmane.comp.file-systems.fuse.sshfs/812

Earth (matt-h) wrote :

This problem is still present in intrepid.

fsname=sshfs does not work for me, I get /bin/sh: fsname=sshfs: not found

Øyvind Jensen (jegerjensen) wrote :

Matt,

I think maybe you used the option wrongly, here is my line from fstab. (exept I made it a bit more anonymous)

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)

Does this help?

goto (gotolaunchpad) wrote :

fsname= works for me.

jimmy dread (jimmydread) wrote :

Adding the "fsname" option to the fstab line fixed this issue for me.

Ryan Thompson (rct86) wrote :

Here is a quick perl one-liner that fixed *my* sshfs fstab lines to use the "fsname" option. You may try it on your own fstab at your own risk.

sudo perl -lape 's/(sshfs#\S+)(\s+\S+\s+\S+\s+)(.*)/\1\2fsname=\1,\3/' -i /etc/fstab

Luke Schlather (luke2760) wrote :

Has anyone talked to upstream about this? The fsname option is annoyingly redundant.

Jens Janssen (jayjay) wrote :

Bug also appears on Jaunty. The quick workaround by adding "fsname=..." works for me.

bdforbes (bdforbes) wrote :

Confirming that bug appears in Jaunty, and that the quick fsname fix works.

Martin Albisetti (beuno) wrote :

Thank you for bringing this bug to our attention. Unfortunately a paper cut should be a small usability issue that affects many people and is quick and easy to fix. I'm afraid this bug can't be addressed as part of this project.
A paper cut is a minor usability annoyance that an average user would encounter on his/her first day of using a new installation of Ubuntu 9.10.

Changed in hundredpapercuts:
status: New → Invalid
shankao (shankao) wrote :

Still happens in lucid beta1 but the fsname workaround works.

description: updated
Markus (doits) wrote :

Still not working on Natty without fsname

summary: - In hardy, sshfs /etc/mtab and /etc/fstab do not match, umount and
- unmount through "Disk Mounter" applet do not work
+ sshfs /etc/mtab and /etc/fstab do not match, umount and unmount through
+ "Disk Mounter" applet / Nautilus do not work
Download full text (3.6 KiB)

I'm out of the office until 1st August.

On 15 May 2011, at 10:43, Markus <email address hidden> wrote:

> Still not working on Natty without fsname
>
> ** Summary changed:
>
> - In hardy, sshfs /etc/mtab and /etc/fstab do not match, umount and
> unmount through "Disk Mounter" applet do not work
> + sshfs /etc/mtab and /etc/fstab do not match, umount and unmount
> through "Disk Mounter" applet / Nautilus do not work
>
> ** Branch linked: lp:ubuntu/natty/sshfs-fuse
>
> --
> You received this bug notification because you are a member of
> Papercutters, which is subscribed to One Hundred Paper Cuts.
> https://bugs.launchpad.net/bugs/243298
>
> Title:
>  sshfs /etc/mtab and /etc/fstab do not match, umount and unmount
>  through "Disk Mounter" applet / Nautilus do not work
>
> Status in One Hundred Paper Cuts:
>  Invalid
> Status in “sshfs-fuse” package in Ubuntu:
>  Confirmed
>
> Bug description:
>  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
>    Candid...

Read more...

paniq (paniq) wrote :

Still broken in 12.10 Quantal. :-/

Still broken 14.04 Trusty Tahr

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers