Bug 1327209 - umount -a -t nfs doesn't umount nfs entries in fstab
Summary: umount -a -t nfs doesn't umount nfs entries in fstab
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Fedora
Classification: Fedora
Component: util-linux
Version: 23
Hardware: x86_64
OS: Linux
unspecified
medium
Target Milestone: ---
Assignee: Karel Zak
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2016-04-14 13:00 UTC by Steeve McCauley
Modified: 2016-04-15 10:58 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2016-04-15 08:40:24 UTC
Type: Bug


Attachments (Terms of Use)

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


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