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.
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.
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.
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 ?
Don't worry, we read user's comments in bugzilla. We're just selecting things for next RHEL updates. You will be informed. Thanks.
I'm curious as to why this has become a private bug...
Moving from "mount" to "util-linux" bugzilla component. The separate mount package is in AS2.1 only. In RHEL3 we have util-linux.
*** Bug 159013 has been marked as a duplicate of this bug. ***
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
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
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
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