Bug 1327209

Summary:	umount -a -t nfs doesn't umount nfs entries in fstab
Product:	[Fedora] Fedora	Reporter:	Steeve McCauley <steeve.mccauley>
Component:	util-linux	Assignee:	Karel Zak <kzak>
Status:	CLOSED NOTABUG	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	medium	Docs Contact:
Priority:	unspecified
Version:	23	CC:	jonathan, kzak, steeve.mccauley
Target Milestone:	---
Target Release:	---
Hardware:	x86_64
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2016-04-15 08:40:24 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:

Description Steeve McCauley 2016-04-14 13:00:20 UTC

Description of problem:

umount -a -t nfs does not all nfs entries described in /etc/fstab.  It dosn't matter if I specify the entries using auto or not, the entries are ignored when attempting to umount.  If I manually umount the nfs mountpoints and run "mount -a -t nfs" it does what is expected".

Version-Release number of selected component (if applicable):


How reproducible:

Consistently

Steps to Reproduce:
1. configure nfs mounts using 'defaults' in fstab
2. umount -a -t nfs
3. nothing unmounted

Actual results:
# umount --verbose -a -t nfs | grep data
/data/osd                : ignored
/data/photos             : ignored
/data/audio              : ignored
/data/household          : ignored


Expected results:
# umount --verbose -a -t nfs | grep data
/data/household          : successfully unmounted
/data/audio              : successfully unmounted
/data/photos             : successfully unmounted
/data/osd                : successfully unmounted

Additional info:

/etc/fstab entries,
linguini:/data/household	/data/household	nfs	defaults 0 0
linguini:/data/audio		/data/audio		nfs	defaults 0 0
linguini:/data/photos		/data/photos	nfs	defaults 0 0
linguini:/data/osd		/data/osd		nfs	defaults 0 0

Comment 1 Karel Zak 2016-04-14 13:13:10 UTC

What about "umount -a -t nfs4"?  (see findmnt output to get fs name).

Note that umount -a does not follow /etc/fstab, but /etc/mtab (so stuff in /proc/mounts on systems without mtab).

Comment 2 Steeve McCauley 2016-04-14 13:34:39 UTC

Okay, this works to umount,

# umount -a -t nfs4

but not,

# mount -a -t nfs4

but this works for mount,

# mount -a -t nfs

So it would seem that mount uses fstab and umount uses mtab?

Changing fstab to type nfs4 allows both mount and umount to operate as expected if I use,

# (u)mount -a -t nfs4

There's a bit of a disconnect between the type mount types nfs and nfs4, not to mention nfsvers support in options from the nfs(5) manpage.

Comment 3 Karel Zak 2016-04-15 08:40:24 UTC

mount(8) reads information from /etc/fstab, umount(8) reads information from /proc/self/mountinfo (or /proc/mounts, or old versions from /etc/mtab).

The information in /proc are generated by kernel.

I'll add a note about this to the umount man page to make it more obvious for users. Thanks.

Comment 4 Steeve McCauley 2016-04-15 10:58:59 UTC

The bug, imo, is that mount will happily mount an nfs4 mount type using the nfs type from fstab and that umount ignores the nfs mount type used by mount.  The bug is in umount when deciding whether to consider a given volume for removal.

Regards