umount: mount disagrees with the fstab

Bug #99437 reported by cseg on 2007-03-31
This bug affects 14 people
Affects Status Importance Assigned to Milestone
util-linux (Ubuntu)
Nominated for Jaunty by Robert Mileski

Bug Description

Binary package hint: mount

I am not root.

I can mount a filing system:

   $ mount /mnt/backups
   (no errors)

I cannot umount the filing system:

   $ umount /mnt/backups
   umount: /mnt/backups mount disagrees with the fstab

My fstab looks like this:

   $ grep backups /etc/fstab
   UUID=52ff9f34-23e4-4b1b-adfe-6d02ed07b5bd /mnt/backups ext3 defaults,errors=remount-ro,user 0 1

Oh, I see that there is more information about this bug here:

And that there is a patch for it here:

The patch is a one line of code fix in fstab.c and mount_blkid.h.

I am using 6.10 Server. This bug is breaking some very important scripts and is very annoying!

I don't suppose you could give this a quick fix.


I can confirm this bug. Fresh install of Feisty Fawn, it worked the other day, but now it isnt working anymore, even with a reboot. Im not root, but Im running as the first user created after install.

Im trying to umount my 2nd IDE hd (/dev/hdd1), and in Gnome, an error message says:
umount: /media/hdd1 mount disagrees with fstab

It doesnt work running umount manually as well.

Attaching my /etc/fstab

Changed in util-linux:
status: Unconfirmed → Confirmed

Marked <a href="">this bug</a> as duplicate of this one.

Frederick Reeve (cylix) wrote :

All three bugs on this are from the same source. This is the fix. I am attaching this patch to all three. I have been using it for a while, its fine. The attached patch should be applied to the src-dep of util-linux. For those of you who want this fix now follow these instructions:

Modify your source.list so you have so the dep-src for the main repository enabled and copy the patch into /tmp. Then run the following commands:

$ sudo apt-get update
$ sudo apt-get install build-essential
$ sudo apt-get build-dep mount
$ cd /tmp
$ apt-get source mount
$ cd util-linux-2.12r
$ ./debian/rules patch
$ patch -Np1 -i ../util-linux_user_mount.patch
$ ./configure
$ make lib
$ make -C mount
$ sudo chown root:root mount/umount
$ sudo chmod 4755 mount/umount
$ sudo mv mount/umount /bin

now you should be able to unmount you drive that was user mounted using a uuid.

That's great, even though I'm not technical enough to understand what the patch actually did. However, I was wondering: it is ok to allow unprivileged users to mount/umount removable devices, but what about fixed devices? Wouldn't it be better if general users be able to mount/umount fixed drives only if they are part of some special group, e.g. "mount" ?

Suppose that I, as "sysadmin" of my home PC, have another HD that I use for backup... I surely wouldn't like my mom or my sister messing around that hd... Well, just my 2 cents.

Changed in util-linux:
status: Confirmed → Fix Released
status: Fix Released → Confirmed

I will change this to Fix Released, even though I didn't test it myself. If this wasn't the correct way to do it, please, let me know. Thanks.

Changed in util-linux:
status: Confirmed → Fix Released
Frederick Reeve (cylix) wrote :

Júlio: Thats true you may not want your mom to do that. In that case the simple way is since you have sudo just make a fstab entry for the drive using uuid and do not put in the user, users or group options. Then you can mount it using sudo and it can not be mounted by a standard user. The other thing you could do is play with the udev rule so it assigns that specific drive a different group than plugdev and set the group option in the fstab. There are even more ways to do this. If your really looking for a solution you can ask me and I'll get you one.

Frederick: you are also correct. I could find my way into this, but I'm thinking about regular users, those who wouldn't understand this or simply prefer not to mess with such "complicated" things as fstab...

Chris Smart (csmart) wrote :

I have applied your patch Frederick and it does let users umount a drive specified in fstab by UUID (thanks), however it still throws up an error saying:
"Cannot eject volume"

But it *does* indeed unmount, for which I'm grateful :) Just wanted to let you know.


Frederick Reeve (cylix) wrote :

Chris: The message "Cannot eject volume." is a separate issue and will not effect usage in any way. I take it you are using Nautilus to "eject" the volume. Nautilus eject does other things besides running umount on the device. Nautilus is using gvm and hence hal for various reasons. The problem is with one of those two. I suspect hal. I may look into this issue also but this is a separate bug. See bug ( ) it is related and shows the problem with hal. This issue will not harm anything but the popup is annoying. The issue that I was patching was the issue with the umount command. This is what was covered here and the on the other bugs I posted the fix at. I have not attempted *yet* to fix this OTHER bug.

Chris Smart (csmart) wrote :

Frederick: You're right, cheers.

ajaxas (ajaxas) wrote :

Yepp, this has fixed the problem for me, and yes - I still get those two error messages ('cannot eject the volume [LABEL]' and another one.
Hope this fix will be included in future updates.

I am seeing this bug again in Ubuntu server 8.04.

Mattias (mattias-webben) wrote :

I am seeing this bug again in Ubuntu 9.04, is this bug still around? Do I need to apply a patch even to such a modern release?

serge k (serge-kobsa) wrote :

Definitely present in 9.04, as late as 2.6.30-rc7-candela

Robert Mileski (mileski) wrote :


This bug affects Ubuntu 9.04, and should be fixed through official repositories. A fix should be released by the maintainers, and it should come as update.

Changed in util-linux (Ubuntu):
status: Fix Released → New
Robert Mileski (mileski) wrote :

Another this about the bug, in fstab the entry does not have to be represented with UUID. It can be any value, and it still doesn't unmount as normal user.

We do not ordinarily backport fixes to older releases - however, if you wish to request that - click "Target to release" - do not change the status of the bug for the _development_ release

Changed in util-linux (Ubuntu):
status: New → Fix Released
Robert Mileski (mileski) wrote :

Hi Scott,

thanks for the remarks. I have nominated the bug fix for Jaunty, but really I don't understand something. Can you please help me understand it?

Bug #99437 reported by cseg on 2007-03-31. This bug was noticed in a release much earlier then Ubuntu 9.04, which ""Jaunty Jackalope" is the code name for Ubuntu 9.04, which was released on 23 April 2009.".

So, the other thing that makes me not understand what you have said is this: "Ubuntu 9.04 (Jaunty Jackalope) will be supported until October 2010".

Now we are May 2010. So when you click on the button Fix released, what do you mean by that?

There is no fix for 8.10, nor for 9.04. Where is the support until 2010 ?

Sorry for my confusion, because I'm a software developer in a company, which supports till now 5 releases of our software, and when we fix a bug, we fix it for all our releases. Then we say a bug has been fixed.

Thanks, Robert.

Ok i have Lucid 10.04 and when i mount a sshfs through fstab:
sshfs#<email address hidden>:/home/user /home/user/remotedisk fuse users,exec,uid=1000,gid=1000,allow_other,reconnect,follow_symlinks 0 0

it mounts ok,
but when i want to umount i get :

umount: /home/user/remotedisk mount disagrees with the fstab

I need to umount with: sudo umount /home/user/remotedisk
So i guess the bug is still there? I have all latest updates (07-01-2010) from Lucid.

Offcourse i meant all updates on july 10th 2010 (07-10-2010)

hcmeyer (hcmeyer) wrote :

I am getting this bug in Meerkat on a samba share. sudo umount works, the fstab line for the share has options noauto, users. All updates thru July 15, 2010 applied.

Martin Lindhe (martinlindhe) wrote :

Robin van Leeuwen: i solved the issue with sshfs mounts like this:

first, create a symlink:

ln -s mount.fuse /sbin/mount.fuse.sshfs

then change the /etc/fstab syntax like this:

<email address hidden>:/media /media/media-server fuse.sshfs user,idmap=user,allow_other,port=62000 0 0

<email address hidden>:/home/user /home/user/remotedisk fuse.sshfs options 0 0

i think maybe the sshfs installer should create that symlink

Martin Lindhe (martinlindhe) wrote :

sorry too fast there, didnt mean to post the real line :O how can i remove that?

Vide (vide80) wrote :

I'm experiencing the same as hcmeyr, Ubuntu 10.10 latest packages installed.
mounting a cifs share present in fstab works with "mount mountpoint" but "umount mountpoint" fails with a "mount disagrees with the fstab". "sudo umount mountpoint" works as expected

Ravi (asvravi) on 2010-10-26
Changed in util-linux (Ubuntu):
status: Fix Released → New
status: New → Confirmed
Ravi (asvravi) wrote :

I can confirm this bug in 10.10. Changing back the status to "Confirmed" since the fix for this bug was never released in the official distribution, although a patch exists.

Peshko R. (peshko-us) wrote :

Ubuntu 10.10 32 bit.

Same here when mounting/unmounting cifs:

user@ubuntu10-lap:~$ mount /media/test
user@ubuntu10-lap:~$ mount
// on /media/test type cifs (rw,mand,nosuid,nodev,user=XXXXX)

user@ubuntu10-lap:~$ umount /media/test
umount: /media/test mount disagrees with the fstab

Here is my fstab:

// /media/test2 cifs rw,iocharset=utf8,credentials=/root/.smbcredentials,file_mode=0777,dir_mode=0777,users 0 0

hcmeyer (hcmeyer) wrote :

Bug still here, samba 3.5.4 updates applied this morning

Gilles Schintgen (shigi) wrote :

I had this same issue with a CIFS mount. An easy solution/workaround can be found here:

Karel Zak (kzak) wrote :

Note that the problem with fuse sshfs should be fixed by util-linux-2.19 (for more detail see the fstab.5 man page and a note about "subtype").

Comment #22 worked for me on my 10.04.2 fully updated. Adding the trailing slash like the last comment did not work. Thanks.

Psy[H[] (vovik-wfa) wrote :

Have this bug on current natty
mounting cifs share with suid'ed mount.cifs is successful, but unmount has... disagreements.

It is now almost six years later since the original bug report (#71609) was filed, and Precise still has this bug (sshfs). The workaround described in post #22 (which I believe stems from here: may work for umount, but it breaks pubkey authentication on mount (I'm prompted for my password even though I have working file-based authentication).

I was under the impression that this was a trivial one-liner bugfix? Why is this still unsolved after six years with a working fix having been released?

Fredde (fredde-iki) wrote :

I found the following solution

In fstab, this line couldn't unmount producing the "umount: mount disagrees with the fstab" error:
sshfs#fredde@host:/dir/ /media/sshfs/mountpoint fuse user,noauto,idmap=user 0 0

Adding the option "fsname=sshfs#user@host:/dir/" did the trick:
sshfs#fredde@host:/dir/ /media/sshfs/mountpoint fuse user,noauto,idmap=user,fsname=sshfs#fredde@host:/dir/ 0 0

The mount now shows up in Nautilus, and can be mounted and unmounted from there like it should.

Sebastian W. (yodamin) wrote :

Fredde's workaround does the trick. Thank you :-)

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

Duplicates of this bug

Other bug subscribers

Bug attachments