Error on unmounting a NFSv4 share
| Affects | Status | Importance | Assigned to | Milestone | |
|---|---|---|---|---|---|
| | nfs-utils (Ubuntu) |
High
|
Unassigned | ||
Bug Description
When unmounting an NFSv4 share I get the following error message:
[mntent]: line <nr.> in /proc/mounts is bad
The umount seems to succeed though.
Package Info:
nfs-common 1:1.2.5-3ubuntu2
Linux 3.2.0-22-generic
| Changed in nfs-utils (Ubuntu): | |
| importance: | Undecided → High |
| Steve Langasek (vorlon) wrote : | #2 |
I can't imagine why the kernel is deleting a mount point here, stale mount or otherwise. But it seems to me this is a bug in umount from util-linux, not in nfs-utils.
| affects: | nfs-utils (Ubuntu) → util-linux (Ubuntu) |
| Van Stokes, Jr. (vstokes) wrote : | #3 |
We just had a similar incident.
The local server autofs mounts a remote NFS. The remote server unexpectidly powered off (no normal shutdown). The remote server was powered back on however the local server was not able to access the remote NFS's. It appears the local server never umounted the remote NFS's. When you did and ls -l a bunch of question marks would appear. We attempted umount the remote mounts but the local server kept saying: {mount} was not found in /proc/mounts.
root@mysql02:/etc# df
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/mapper/
udev 6143968 4 6143964 1% /dev
tmpfs 2461300 516 2460784 1% /run
none 5120 0 5120 0% /run/lock
none 6153244 0 6153244 0% /run/shm
/dev/sdg1 233191 98407 122343 45% /boot
/dev/md0 3845737480 590404808 3059980404 17% /d01
logilive:
lwt1:/opt/logisoft 24520704 11627520 11646976 50% /net/lwt1/
root@mysql02:/etc# umount /net/logilive/
/net/logilive/
/net/logilive/
we could never get the local server to umount the remote server. We had to reboot the local server.
| bluearcus (mike-miller-gmx) wrote : | #4 |
This problem is not limited to stale mounts.
It's an error in the interaction between mount, umount and mount details in /proc/mounts vs /etc/mtab
In /etc/mtab, nfs4 mounts seem to have a problem with leading slashes.
For example, on my 12.04 client machine, mounting a zfs volume on a 12.04 host, the following works fine:
me@client:/$ sudo mount -t nfs bighost:/remotevol /mnt/target
me@client:/$ sudo umount /mnt/target
me@client:/$
No issues.
However, the mount command will accept the volume spec without the leading slash and mount it:
me@client:/$ sudo mount -t nfs bighost:remotevol /mnt/target
me@client:/$ sudo umount /mnt/target
/mnt/target was not found in /proc/mounts
/mnt/target was not found in /proc/mounts
me@client:/$
And the the remotevol is not unmounted.
umount fails to identify the mounted volume in /proc/mounts because, when mounted without the leading slash, it is denoted differently between /proc/mounts and the entry in /etc/mtab
me@client:/$ grep /mnt/target /etc/mtab
bighost:remotevol /mnt/target nfs rw,vers=
me@client:/$ grep /mnt/target /proc/mounts
bighost:/remotevol/ /mnt/target nfs4 rw,relatime,
To fix at time of the error, edit mtab for the un-umountable volume and add a leading slash to the volume path specifier... then unmount and it will work.
To prevent the error occurring, always specify volume paths with a leading slash on the command line or in fstab...
Real fix... I guess mount should require a leading slash on the volume name, and it's a bug that it doesn't?
| Brian Candler (b-candler) wrote : | #5 |
I think the remote volume with/without leading slash is different to the \040(deleted) problem. I have a machine in the latter state:
# grep monster3 /etc/mtab
192.168.
# grep monster3 /proc/mounts
192.168.
# umount /media/monster3
/media/monster3 was not found in /proc/mounts
/media/monster3 was not found in /proc/mounts
root@proliant:~# umount /media/monster3
root@proliant:~# umount "/media/monster3 "
umount: /media/monster3 : not found
root@proliant:~# umount "/media/monster3 (deleted)"
umount: /media/monster3 (deleted): not found
I tried some variations of editing what's in /etc/mtab, adding \040 or \040(deleted), and variations of what I pass to umount, to no avail.
| Dale (dale-jolliff) wrote : | #6 |
I'm seeing this too - \040(deleted) added to the end of the entry in /proc/mounts - the entry there is the only different anywhere else.
I hated the 'hang' you would get with a stale NFS v3 mount but it was a heck of a lot better than being forced to reboot a server!
What is the workaround for this bug? Any time frame on a fix?
| Chiyuan Zhao (chiyuan-zhao) wrote : | #7 |
I managed to solve the \040(deleted) problem.
Edit the /etc/mtab, add the \040(deleted) to the end of mount path, then use mount to show the new path. Then you can use the umount.nfs4 "/your/mount/path (deleted)" -f to umount it.
Linux xxxxxx 3.2.0-23-generic #36-Ubuntu SMP Tue Apr 10 20:39:51 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux
| Chiyuan Zhao (chiyuan-zhao) wrote : | #8 |
This is not a graceful unmount. You still hang if you try to ls/cd the mount path.
Just got hit by the same thing and completely unrelated to comment #4. We had this with fully formed paths (with slashes) and an NFS server that went away suddenly. Trying unmount with -f , -l and those two flags in combination did not solve the issue. When I tried the suggestion in #7 I found it only has the effect of removing the line describeing the mount in /etc/mtab but not in /proc/mounts or actually doing an umount. This is why, I think, the poster gets the hang in his next comment (#8) as the mount is not actually unmounted, just no longer tracked in /etc/mtab.
Forgot to inlcude uname -a:
3.2.0-51-generic #77-Ubuntu SMP Wed Jul 24 20:18:19 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux
This is also tracked here:
http://
http://
http://
| Raphael Thoma (raphithom-4) wrote : | #11 |
We saw today the same error on our linux boxes after a takeover has been executed on the netapp heads.
All mountpoints we're visible as "/mountpoint (deleted)" in /proc/mounts - however the mountpoints were still usable but couldn't be unmounted without the /etc/mtab workaround (add \040(deleted) to the end of mount path).
Uname -a:
Linux <hostname>-3 3.2.0-49-generic #75-Ubuntu SMP Tue Jun 18 17:39:32 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux
| Phillip Susi (psusi) wrote : | #12 |
This did belong in nfs-utils as it provides the (u)mount.nfs4 helpers.
| affects: | util-linux (Ubuntu) → nfs-utils (Ubuntu) |
| Joe Breu (breu) wrote : | #13 |
Still seeing this on 12.04 with kernel 3.8.0-29-generic
| Till Backhaus (tback) wrote : | #14 |
Same here on 12.04 with kernel 3.2.0-70-generic
| Bert Hutzler (bhutzler) wrote : | #15 |
uuhhh, probably someone repaired this to bits.
I did a nfs mount using the leading slash (wondering what may be on so.'s mind to omit it???),
and got into exatly that problem, OS stating "not found in /proc/mounts", because of different entries there and in /etc/mtab.
But in my case there are two slashes in /proc/mounts!!!
uname -a:
Linux ubuntubert 3.2.0-88-generic #126-Ubuntu SMP Mon Jul 6 21:33:03 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux
Although I could unmount editing /etc/mtab, this is a bug and should be fixed.
| WIll Salmon (will-salmon) wrote : | #16 |
We get this problem on servers 12.04.5 running Trusty kernel 3.13.0-65-generic (and on 12.04.4 running Quantal kernel 3.5.0-54 )
/etc/fstab has a slash at the start of the NFS server path
/proc/mounts has an unnecessary extra "/" on the NFS path: like this :-
nfs-server:
whereas /etc/mtab correctly does not ...
nfs-server:
This is a nasty bug in a basic utility (umount.nfs) and really should be fixed !!
| WIll Salmon (will-salmon) wrote : | #17 |
Two identical error messages on trying to umount an NFS mount as follows :
/export/
/export/


This also happens when unmounting a stale NFS share
nas:/raid/www /home/www\ 040(deleted) nfs4 rw,noatime, vers=4, rsize=8192, wsize=8192, namlen= 255,hard, proto=tcp, port=0, timeo=600, retrans= 10,sec= sys,clientaddr= 192.168. 100.11, minorversion= 0,local_ lock=none, addr=192. 168.100. 40 0 0
root@back2:~# umount -f /home/www
/home/www was not found in /proc/mounts
/home/www was not found in /proc/mounts
It can't find /home/www in /proc/mounts because it has been renamed to /home/www\ 040(deleted) by the kernel