Bug 149894

Summary: `umount -f` does not appear to actually work
Product: Red Hat Enterprise Linux 3 Reporter: Paul Waterman <paulwaterman>
Component: util-linuxAssignee: Karel Zak <kzak>
Status: CLOSED ERRATA QA Contact: Ben Levenson <benl>
Severity: medium Docs Contact:
Priority: medium    
Version: 3.0CC: brilong, joshua, k.georgiou, swellnit
Target Milestone: ---   
Target Release: ---   
Hardware: i686   
OS: Linux   
Whiteboard:
Fixed In Version: RHBA-2005-669 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2005-10-05 16:50:30 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 156320, 156322    
Attachments:
Description Flags
Proposed updates to the umount.8 man page none

Description Paul Waterman 2005-02-28 17:34:15 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.3)
Gecko/20040910

Description of problem:
Running /bin/umount -f [filesystem] SHOULD be able to forcibly unmount
an NFS-mounted filesystem, even if there are open file handles, etc.,
on that filesystem or if the mount is stale due to the remote server
or filesystem no longer being available.

However, the -f option doesn't appear to make any difference. For example:

% umount /mnt/x
umount: /mnt/x: device is busy

% umount -f /mnt/x
umount2: Device or resource busy
umount: /mnt/x: device is busy

I have tested this with various mount options, with NFS exports from
Network Appliance NAS servers as well as other Linux systems, and with
the NFS mount being kept "busy" both via shell simply sitting in the
directory and via a file open on the filesystem -- none of this
appears to make any difference.

Needless to say, the ability to forcibly unmount NFS mounts in large
enterprise configurations is fairly important.

Version-Release number of selected component (if applicable):
mount-2.11y-31.1, mount-2.11y-31.2

How reproducible:
Always

Steps to Reproduce:
1. mount nfsserver:/remote/filesystem /local/mount/point
2. cd /local/mount/point
3. umount -f /local/mount/point
    

Actual Results:  umount2: Device or resource busy
umount: /local/mount/point: device is busy

Expected Results:  /local/mount/point should unmount.

Comment 1 Paul Waterman 2005-03-24 22:16:41 UTC
Turns out that this isn't actually a problem with the umount command as much as
it's a matter of unclear documentation.

The -f (force) option does NOT actually unconditionally force an unmount. It
still requires that the file system be idle -- if the file system is busy, the
umount will fail even with a -f option. The -f option is ONLY useful in the
instance where the NFS server is no longer available and the file system is idle.

The -l (lazy) option is what I was looking for. This actually forces the unmount
regardless of whether or not the file system is busy.

This is extremely likely to trip up people working in a mixed Solaris/Linux
environment or coming from a Solaris background, as the -f (force) option was a
highly touted feature of Solaris 8 and beyond that actually *forces* the unmount
regardless of whether or not the file system is idle.

The umount man page should be updated to make the distinction between -f and -l
more clear.

Comment 2 Paul Waterman 2005-05-26 22:49:37 UTC
Created attachment 114896 [details]
Proposed updates to the umount.8 man page

The following attachment provides diffs for a proposed update to the umount.8
man page. This update will provide further clarification to the -f and -l
umount options, making it clear that the -f option cannot be used to umount
busy filesystems and that the -l option should be used instead for that
purpose.

Comment 3 Joshua Jensen 2005-05-27 17:47:39 UTC
No response for almost 3 months?  This is a good idea... -f vs -l needs to be
better explained.  When can this find it's way into the umount manpage for RHEL3
and REHL4 ?

Comment 4 Karel Zak 2005-05-27 18:59:56 UTC
Don't worry, we read user's comments in bugzilla. We're just selecting things
for next RHEL updates. You will be informed. Thanks.

Comment 7 Paul Waterman 2005-05-31 16:02:54 UTC
I'm curious as to why this has become a private bug...

Comment 11 Karel Zak 2005-07-18 08:18:13 UTC
Moving from "mount" to "util-linux" bugzilla component. The separate mount
package is in AS2.1 only. In RHEL3 we have util-linux.

Comment 12 Karel Zak 2005-07-18 10:20:55 UTC
*** Bug 159013 has been marked as a duplicate of this bug. ***

Comment 13 Paul Waterman 2005-07-18 18:19:13 UTC
Comment #11 is incorrect. In RHEL 3.0, the /bin/mount command is contained in
the mount RPM. This changed to util-linux in RHEL 4.0 (not 3.0). Since this bug
is against RHEL 3.0, the component should remain mount.

% cat /etc/redhat-release; rpm -qf /bin/mount
Red Hat Enterprise Linux WS release 3 (Taroon Update 5)
mount-2.11y-31.6

% cat /etc/redhat-release; rpm -qf /bin/mount
Red Hat Enterprise Linux WS release 4 (Nahant Update 1)
util-linux-2.12a-16.EL4.6

Comment 14 Karel Zak 2005-07-19 05:40:44 UTC
The basic buzilla components are connected with source rpm packages:

$ cat /etc/redhat-release; rpm -q --qf "%{SOURCERPM}\n" mount;
Red Hat Enterprise Linux AS release 3 (Taroon Update 5)
util-linux-2.11y-31.6.src.rpm


Comment 18 Red Hat Bugzilla 2005-09-28 15:52:03 UTC
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on the solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHBA-2005-626.html


Comment 19 Red Hat Bugzilla 2005-10-05 16:50:30 UTC
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on the solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHBA-2005-669.html