Description of problem: Hello, I noticed recently after a yum update that users aren't able to unmount nfs shares that have previously mounted. This also breaks mounting/unmounting by clicking on predefined network locations in nautilus; mounting works but unmounting doesn't. Here is my fstab: homeserver:/ /media/nfs-homeserver nfs4 sec=krb5p,users,soft,timeo=10,retrans=1,retry=1,noauto,_netdev 0 0 ------------ Mounting example: └─[17:52]-> mount -vvv /media/nfs-homeserver/Pictures/ mount: fstab path: "/etc/fstab" mount: mtab path: "/etc/mtab" mount: lock path: "/etc/mtab~" mount: temp path: "/etc/mtab.tmp" mount: UID: 500 mount: eUID: 0 mount: spec: "homeserver:/Pictures" mount: node: "/media/nfs-homeserver/Pictures" mount: types: "nfs4" mount: opts: "sec=krb5p,users,soft,timeo=10,retrans=1,retry=1,noauto,_netdev" mount: external mount: argv[0] = "/sbin/mount.nfs4" mount: external mount: argv[1] = "homeserver:/Pictures" mount: external mount: argv[2] = "/media/nfs-homeserver/Pictures" mount: external mount: argv[3] = "-v" mount: external mount: argv[4] = "-o" mount: external mount: argv[5] = "rw,noexec,nosuid,nodev,noauto,users,_netdev,sec=krb5p,soft,timeo=10,retrans=1,retry=1" mount.nfs4: timeout set for Sat May 21 17:53:23 2011 mount.nfs4: trying text-based options 'sec=krb5p,soft,timeo=10,retrans=1,retry=1,addr=10.10.10.10,clientaddr=10.10.10.5' homeserver:/Pictures on /media/nfs-homeserver/Pictures type nfs4 (sec=krb5p,users,soft,timeo=10,retrans=1,retry=1,noauto,_netdev) ------------ Unmounting example: └─[17:53]-> umount -vvv /media/nfs-homeserver/Pictures/ Trying to unmount /media/nfs-homeserver/Pictures umount.nfs4: You are not permitted to unmount /media/nfs-homeserver/Pictures umount.nfs4: You are not permitted to unmount /media/nfs-homeserver/Pictures └─[17:53]-> sudo umount -vvv /media/nfs-homeserver/Pictures/ Trying to unmount /media/nfs-homeserver/Pictures NFSv4 mount point detected homeserver:/Pictures umounted ------------ Version-Release number of selected component (if applicable): I'm not exactly sure what component is the culprit here, but I'm guessing nfs. nfs-utils-1.2.3-11.fc15.x86_64 How reproducible: always Steps to Reproduce: 1. mount share as user 2. umount same share as user 3. Actual results: operation not permitted Expected results: operation permitted Additional info: I just happen to use kerberos, but the same thing happens when I turn kerberos off. Also just from googling around I came across this, which might be the same error but on suse: https://bugzilla.novell.com/show_bug.cgi?id=681106, and this post on debian mailing list http://lists.debian.org/debian-kernel/2011/03/msg00665.html
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