This service will be undergoing maintenance at 00:00 UTC, 2016-08-01. It is expected to last about 1 hours
Bug 706657 - "users" option in fstab allows nonroot users to mount shares, but not unmount them
"users" option in fstab allows nonroot users to mount shares, but not unmount...
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: nfs-utils (Show other bugs)
15
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Steve Dickson
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2011-05-21 21:00 EDT by Dirk Cummings
Modified: 2012-08-08 00:41 EDT (History)
7 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-08-07 14:39:29 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Dirk Cummings 2011-05-21 21:00:29 EDT
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
Comment 1 Joe Christy 2011-06-27 16:36:29 EDT
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.
Comment 2 Dirk Cummings 2011-06-27 22:37:32 EDT
@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.
Comment 3 Ferry Huberts 2011-09-23 10:11:55 EDT
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....
Comment 4 Jeff Layton 2011-09-23 10:23:42 EDT
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.
Comment 5 Ferry Huberts 2011-09-23 11:18:43 EDT
(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
Comment 6 Richard Ryniker 2011-11-10 09:07:49 EST
Also occurs in F16.
Comment 7 Frank Murphy 2012-01-01 15:10:04 EST
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,
Comment 8 Fedora End Of Life 2012-08-07 14:39:32 EDT
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
Comment 9 Ferry Huberts 2012-08-08 00:41:29 EDT
please reopen on F17

Note You need to log in before you can comment on or make changes to this bug.