umount: mount disagrees with the fstab

Bug #99437 reported by cseg
112
This bug affects 14 people
Affects Status Importance Assigned to Milestone
util-linux (Ubuntu)
Confirmed
Undecided
Unassigned
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:

   https://launchpad.net/ubuntu/+source/util-linux/+bug/71609

And that there is a patch for it here:

   http://librarian.launchpad.net/5596114/util-linux_mount.patch

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.

Thanks!

Revision history for this message
Júlio Alexandrino (alexandrino) wrote :

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
Revision history for this message
Júlio Alexandrino (alexandrino) wrote :

Marked <a href="https://bugs.launchpad.net/ubuntu/+source/gnome-volume-manager/+bug/104693">this bug</a> as duplicate of this one.

Revision history for this message
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.

Revision history for this message
Júlio Alexandrino (alexandrino) wrote :

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
Revision history for this message
Júlio Alexandrino (alexandrino) wrote :

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
Revision history for this message
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.

Revision history for this message
Júlio Alexandrino (alexandrino) wrote :

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...

Revision history for this message
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.

-c

Revision history for this message
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 ( https://bugs.launchpad.net/bugs/63090 ) 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.

Revision history for this message
Chris Smart (csmart) wrote :

Frederick: You're right, cheers.

Revision history for this message
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.

Revision history for this message
Chris Rossi (chris-archimedeanco) wrote :

I am seeing this bug again in Ubuntu server 8.04.

Revision history for this message
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?

Revision history for this message
serge k (serge-kobsa) wrote :

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

Revision history for this message
Robert Mileski (mileski) wrote :

Hi,

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
Revision history for this message
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.

Revision history for this message
Scott James Remnant (Canonical) (canonical-scott) wrote :

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
Revision history for this message
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.

Revision history for this message
Robin van Leeuwen (robinvanleeuwen) wrote :

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.

Revision history for this message
Robin van Leeuwen (robinvanleeuwen) wrote :

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

Revision history for this message
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.

Revision history for this message
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

Revision history for this message
Martin Lindhe (martinlindhe) wrote :

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

Revision history for this message
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)
Changed in util-linux (Ubuntu):
status: Fix Released → New
status: New → Confirmed
Revision history for this message
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.

Revision history for this message
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
.
.
//xxx.xxx.xxx.xxx/myfolder/ 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:

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

Revision history for this message
hcmeyer (hcmeyer) wrote :

Bug still here, samba 3.5.4 updates applied this morning

Revision history for this message
Gilles Schintgen (shigi) wrote :

I had this same issue with a CIFS mount. An easy solution/workaround can be found here:
https://bugs.launchpad.net/cifs-utils/+bug/661025/comments/4

Revision history for this message
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").

Revision history for this message
Esteban Carnevale (estebancarnevale) wrote :

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

Revision history for this message
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.

Revision history for this message
Daniel Smedegaard Buus (danielbuus) wrote :

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: http://www.unicom.com/blog/entry/651) 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?

Revision history for this message
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.

Revision history for this message
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  
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Bug attachments

Remote bug watches

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