Bug 706657

I see this problem, with a fully updated to 2011-06-28 F15 machine.
After reading other bug reports, it seems to me that the problem is the disparity between fstab and proc/mounts, wrt trailing slashes, e.g.

shango(V) mount /ahab
shango(V) umount /ahab
umount: /ahab mount disagrees with the fstab
shango(V) egrep /ahab /etc/fstab
moby:/ahab      /ahab           nfs     user,noauto,bg
shango(V) egrep /ahab /proc/mounts
moby:/ahab/ /ahab nfs4 rw,relatime,vers=4,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,port=0,timeo=600,retrans=2,sec=sys,clientaddr=172.24.4.64,minorversion=0,local_lock=none,addr=172.24.4.16 0 0

Two additional comments:
1)root has no problem umounting user mounts (duh).
2) This explains the following *extremely* annoying behavior: when I simply logout a/o shutdown, w/o first umounting nfs shares as root, shutdown wedges, irrecoverably at the stage of unmounting filesystems. The only way to recover is to force a power cycle. On a machine w/ soft RAID managed through mdm, this means that at reboot, the machine needs to re-sync the soft RAID, which takes considerable time and resources.

@Joe Christy, I confirm the same behavior when trying to shutdown my laptop while forgetting to unmount user shares first; only the sysrq keys or yanking the power can successfully get passed the frozen nfs process.

I can confirm this bug.

/etc/fstab entry:
qnap859:/Multimedia  /mnt/qnap859/Multimedia  nfs  defaults,noauto,users,nfsvers=3,bg 0 0


I can mount /mnt/qnap859/Multimedia as non-root but not unmount

/proc/mounts:
qnap859:/Multimedia/ /mnt/qnap859/Multimedia nfs rw,relatime,vers=3,rsize=32768,wsize=32768,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,mountaddr=192.168.160.20,mountvers=3,mountport=59904,mountproto=udp,local_lock=none,addr=192.168.160.20 0 0




see also
https://bugs.launchpad.net/ubuntu/+source/util-linux/+bug/99437
https://launchpad.net/ubuntu/+source/util-linux/+bug/71609

it appears this is a long standing bug....

The problem is likely the change /etc/mtab to a symlink to /proc/mounts. The kernel nfs code does not currently take care to ensure that the device string in /proc/mounts is identical to the one passed in the mount() call. That probably will need to be fixed.

A temporary workaround would be to add the trailing '/' to the "device" in /etc/fstab. So for the case in comment #3:

    qnap859:/Multimedia

...if you change that to read:

    qnap859:/Multimedia/

...then it will likely work. I don't think the situation in the original description though will likely ever work. You have:

    homeserver:/

...but you're trying to unmount something under there:

    homeserver:/Pictures

The latter filesystem was automounted by the kernel and the "users" option has no bearing on it. Unmounting homeserver:/ though should still work. It is required that the filesystems for "users" and "user=" options be listed explicitly.

(In reply to comment #4)
> The problem is likely the change /etc/mtab to a symlink to /proc/mounts. The
> kernel nfs code does not currently take care to ensure that the device string
> in /proc/mounts is identical to the one passed in the mount() call. That
> probably will need to be fixed.
> 
> A temporary workaround would be to add the trailing '/' to the "device" in
> /etc/fstab. So for the case in comment #3:

did so

> 
>     qnap859:/Multimedia
> 
> ...if you change that to read:
> 
>     qnap859:/Multimedia/
> 
> ...then it will likely work. I don't think the situation in the original
> description though will likely ever work. You have:
> 

fail:

$ umount /mnt/qnap859/Multimedia
umount.nfs: You are not permitted to unmount /mnt/qnap859/Multimedia
umount.nfs: You are not permitted to unmount /mnt/qnap859/Multimedia

$ umount /mnt/qnap859/Multimedia/
umount.nfs: You are not permitted to unmount /mnt/qnap859/Multimedia
umount.nfs: You are not permitted to unmount /mnt/qnap859/Multimedia

Also occurs in F16.

Similar problem across, F15\F16\F17(Rawhide)

I can mount and umount of  "users" in /etc/fstab on one F16.x86_64 box only 
using a launcher /usr/bin/usermount

All boxes use the  /usr/bin/usermount (launcher)

my.nas.here://nfs/store01  /home/frank/Net01                                        nfs     users,rw,noauto,hard,intr            0 0
my.nas.here://nfs/virtual  /home/frank/Virtual                                          nfs     users,rw,noauto,hard,intr            0 0
my.nas.here://nfs/torrents /home/frank/Torrents                                     nfs     users,rw,noauto,hard,intr            0 0

These three mounts are the same across F16, F17\Rawhide which don't work
just mount only.

kernel-3.1.6-1.fc16.x86_64
autofs-5.0.6-3.fc16.x86_64
nfs-utils-1.2.5-3.fc16.x86_64

When clicking the "unmount" button on launcher this is the error:
umount: /home/frank/Virtual mount disagrees with the fstab

ls -l /home/frank shown nothing out of place chown wise

*network.service is used,

This message is a notice that Fedora 15 is now at end of life. Fedora
has stopped maintaining and issuing updates for Fedora 15. It is
Fedora's policy to close all bug reports from releases that are no
longer maintained. At this time, all open bugs with a Fedora 'version'
of '15' have been closed as WONTFIX.

(Please note: Our normal process is to give advanced warning of this
occurring, but we forgot to do that. A thousand apologies.)

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, feel free to reopen
this bug and simply change the 'version' to a later Fedora version.

Bug Reporter: Thank you for reporting this issue and we are sorry that
we were unable to fix it before Fedora 15 reached end of life. If you
would still like to see this bug fixed and are able to reproduce it
against a later version of Fedora, you are encouraged to click on
"Clone This Bug" (top right of this page) and open it against that
version of Fedora.

Although we aim to fix as many bugs as possible during every release's
lifetime, sometimes those efforts are overtaken by events. Often a
more recent Fedora release includes newer upstream software that fixes
bugs or makes them obsolete.

The process we are following is described here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

please reopen on F17