Error on unmounting a NFSv4 share

[Christian Diefenbach]

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

[Marc Cluet (lynxman)]

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

[Steve Langasek (vorlon)]

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.

[Van Stokes, Jr. (vstokes)]

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/mysql02-root 716514760 11255404 668862508 2% /
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:/opt/logisoft 816146560 176438624 597581376 23% /net/logilive/opt/logisoft
lwt1:/opt/logisoft 24520704 11627520 11646976 50% /net/lwt1/opt/logisoft

root@mysql02:/etc# umount /net/logilive/opt/logisoft

/net/logilive/opt/logisoft was not found in /proc/mounts
/net/logilive/opt/logisoft was not found in /proc/mounts

we could never get the local server to umount the remote server. We had to reboot the local server.

[bluearcus (mike-miller-gmx)]

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=4,addr=192.168.1.19,clientaddr=192.168.1.128 0 0
me@client:/$ grep /mnt/target /proc/mounts
bighost:/remotevol/ /mnt/target nfs4 rw,relatime,vers=4,rsize=262144,wsize=262144,namlen=255,hard,proto=tcp,port=0,timeo=600,retrans=2,sec=sys,clientaddr=192.168.1.128,minorversion=0,local_lock=none,addr=192.168.1.19 0 0

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)]

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.6.117:/share /media/monster3 nfs4 rw,noatime,addr=192.168.6.117,clientaddr=192.168.6.110 0 0
# grep monster3 /proc/mounts
192.168.6.117:/share /media/monster3\040(deleted) nfs4 rw,noatime,vers=4,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=192.168.6.110,minorversion=0,local_lock=none,addr=192.168.6.117 0 0
# 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)]

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)]

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)]

This is not a graceful unmount. You still hang if you try to ls/cd the mount path.

[ALU (c-launchpadmail)]

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.

[ALU (c-launchpadmail)]

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://bugs.debian.org/cgi-bin/bugreport.cgi?bug=711183
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=711184
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=711187

[Raphael Thoma (raphithom-4)]

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)]

This did belong in nfs-utils as it provides the (u)mount.nfs4 helpers.

[Joe Breu (breu)]

Still seeing this on 12.04 with kernel 3.8.0-29-generic

[Till Backhaus (tback)]

Same here on 12.04 with kernel 3.2.0-70-generic

[Bert Hutzler (bhutzler)]

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)]

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://home/users /export/home/nfshomes nfs4 .....

whereas /etc/mtab correctly does not ...

nfs-server:/home/users /export/home/nfshomes

This is a nasty bug in a basic utility (umount.nfs) and really should be fixed !!

[WIll Salmon (will-salmon)]

Two identical error messages on trying to umount an NFS mount as follows :
/export/home/nfshomes was not found in /proc/mounts
/export/home/nfshomes was not found in /proc/mounts

[DACBARBOS Brand (dacbarbos)]

My double slash in /proc/mounts experience was as follows:
- trying umount /mnt/target got me two 'not found' lines;
- trying umount.nfs4 /mnt/target got me one 'not found' line;
- workaround: edit /etc/mtab and delete the matching line (even if correct) then re-run umount.nfs4 /mnt/target.
Other people reaching this page, please click "affects me" on top (just below the error description/title). The more affected users the better. Otherwise this will not get the attention and priority it deserves. My kernel was 3.19.0-58 on R12.04 (precise).