Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.
RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.

Bug 1172297

Summary: umount: don't call umount helpers on --fake
Product: Red Hat Enterprise Linux 6 Reporter: Rachel Kroll <rkroll>
Component: util-linux-ngAssignee: Karel Zak <kzak>
Status: CLOSED ERRATA QA Contact: Tomas Dolezal <todoleza>
Severity: medium Docs Contact:
Priority: medium    
Version: 6.3CC: phil, psklenar, tcallawa, todoleza
Target Milestone: rc   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: util-linux-ng-2.17.2-12.19.el6 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2016-05-11 00:34:44 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:
Embargoed:
Bug Depends On:    
Bug Blocks: 1270825    

Description Rachel Kroll 2014-12-09 19:31:45 UTC
Description of problem:

'umount --fake' winds up calling umount.nfs which checks /proc/mounts for the target and that gives up since it's already gone.

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

2.17.2-12.7.el6_3

How reproducible:

Always

Steps to Reproduce:
1. mount something via NFS
2. umount that same path but leave it in mtab (umount -n, for instance, or call umount2() yourself)
3. 'umount --fake /that/path' --> "/that/path was not found in /proc/mounts"

Actual results:

The line stays in /etc/mtab

Expected results:

mtab entry removed

Additional info:

Hit on CentOS 6.3, but nothing indicates this is local to CentOS or solved upstream in a later build of util-linux-ng.

'umount --fake' was introduced with util-linux-ng-2.17-umount-fake.patch.

Comment 2 Karel Zak 2014-12-10 08:35:27 UTC
You're right, the "fake" flag is not propagated to mount helpers, but umount code assumes that mtab entry has been removed by the helper. It's bug.

Comment 4 Tom "spot" Callaway 2015-05-27 18:42:22 UTC
It seems like there are two options to resolve this:

1) Fix the helpers to handle the "fake" flag, then propogate the "fake" flag to the helpers. Helpers remove the mtab entry. That doesn't seem like it covers this case completely though.

2) Edit the writemtab: jump point code. Currently, it looks like this:

*****

writemtab:
        if (!nomtab &&
            (umnt_err == 0 || umnt_err == EINVAL || umnt_err == ENOENT)) {
                update_mtab (node, NULL);
        }
...

*****

It seems like we might be able to cover this by doing this instead:

writemtab:
        if ((fake) || (!nomtab &&
            (umnt_err == 0 || umnt_err == EINVAL || umnt_err == ENOENT))) {
                update_mtab (node, NULL);
        }

...

*****

Assuming that if we're doing a --fake umount, we always want to update the mtab. I'm guessing that's the point of doing the --fake umount, at least for the original bug reporter.

Then again, I might not have understood this entirely. This older mount code looks nothing like the current stuff.

Comment 5 Phil Dibowitz 2015-05-27 19:02:56 UTC
I haven't looked at modern versions of this code, we delved into the CentOS6 version... but as I recall, mount passes --fake to mount.nfs which does not then pass it back to mount. So without pulling up the code right now, I'm guessing that even if you made that writemtab change, you'd still get an error from `mount`. It may be that there's two bugs in here.

Comment 6 Tom "spot" Callaway 2015-05-27 20:36:12 UTC
I'm pretty sure the version of the umount code being used in EL6 doesn't pass --fake to a helper. I'm also pretty sure that the nfs helper doesn't know what to do with it if it was passed. :)

Comment 7 Karel Zak 2015-05-28 11:29:21 UTC
The --fake option is unsupported by umount.<type> helpers, it's the same in old umount (rhel6) as well as in the current upstream code. The good news is that rhel6 is the last release with /etc/mtab :-)

I think Tom is right, it should be enough to clean up mtab and we probably don't have to call the helper at all if --fake specified. This is necessary to fix in the current upstream code too.

Comment 8 Karel Zak 2015-06-03 09:08:17 UTC
The upstream commit 28cdf9c61206034b733bf5dcbdea179b8238271f fixes libmount to not call umount helpers on --fake.

Comment 14 errata-xmlrpc 2016-05-11 00:34:44 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://rhn.redhat.com/errata/RHBA-2016-0911.html