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.
Cause: The function cache_get_offset() which returns offsets to be mounted that are within the current current subtree for the mount-as-you-go functionality was not returning the correct map entries.
Consequence: This prevented mounts higher up in the tree from being mounted because nested offset triggers created within these mounts would make them look like they weren't mount points to the autofs kernel module.
Fix: The offset selection function was modified to return the correct offsets for the given level of the mount tree.
Result: Mount trees are now mounted "as-you-go" in the correct order so that mounts higher up in the tree are no longer prevented from being mounted.
DescriptionPetter Reinholdtsen
2015-03-18 08:35:58 UTC
Description of problem:
Unrelated but similar-looking NFS exports can block parent mount
points from mounting.
Version-Release number of selected component (if applicable):
autofs-5.0.5-109.el6_6.1.x86_64
How reproducible:
Set up a NFS server X exporting these paths:
/pxx/
/pxx/home/
/pxx/data/colossus/
/pxx-readonly/
Next, set up autofs on a client machine with /net/ set up to automatically
mount NFS servers. Next, on the client machine, try to visit /net/X/pxx/home/.
This will cause /pxx/home/ to be mounted, but the /pxx/ mount points is not.
If the /pxx-readonly/ NFS export do not exist, the /pxx/ mount point is
mounted as it should be. When it is present, /pxx/ mounting is blocked.
Only the autofs mount point is mounted on /net/X/pxx/, but no NFS mount point.
(In reply to Petter Reinholdtsen from comment #3)
> I'll be happy to. How do I create one?
Ensure that syslog is getting facility daemon level debug.
I usually put something like:
daemon.* /var/log/debug
in /etc/rsyslog.conf, touch /var/log/debug and restart rsyslog.
Then remove the comment from the logging configuration entry
in /etc/autofs.conf and change it to:
logging = debug
And that should do the trick.
Comment 5Petter Reinholdtsen
2015-03-18 12:46:35 UTC
Look like it. Got lots of debug lines (but none mentioning the
problematic export points. :( ). But the log had information we would
rather not share on the indexed and open Internet (host names and mount
point names). Can I share it with you outside bugzilla, for example by
direct email?
(In reply to Petter Reinholdtsen from comment #5)
> Look like it. Got lots of debug lines (but none mentioning the
> problematic export points. :( ). But the log had information we would
> rather not share on the indexed and open Internet (host names and mount
> point names). Can I share it with you outside bugzilla, for example by
> direct email?
Sure, email is in the bug info.
(In reply to Ian Kent from comment #6)
> (In reply to Petter Reinholdtsen from comment #5)
> > Look like it. Got lots of debug lines (but none mentioning the
> > problematic export points. :( ). But the log had information we would
> > rather not share on the indexed and open Internet (host names and mount
> > point names). Can I share it with you outside bugzilla, for example by
> > direct email?
>
> Sure, email is in the bug info.
I've been able to duplicate this with the info you provided.
It will take a while to work out what's causing the problem
because, unfortunately, the "mount as you go" code is quite
complicated.
Comment 11Petter Reinholdtsen
2015-03-26 08:36:07 UTC
I've tested the new autofs rpm on a installation with the problematic directory
structure, and can confirm that the pxx-readonly NFS export no longer create any
problems with the pxx mount point next to it. Thank you very much!
When will this fix show up in RHEL? Any hope to get it into RHEL 6?
(In reply to Petter Reinholdtsen from comment #11)
> I've tested the new autofs rpm on a installation with the problematic
> directory
> structure, and can confirm that the pxx-readonly NFS export no longer create
> any
> problems with the pxx mount point next to it. Thank you very much!
>
> When will this fix show up in RHEL? Any hope to get it into RHEL 6?
Not sure yet, we're waiting for a QA ack.
Not sure if it's too late for 6.7 either, since QA began a
while ago, which is essentially a code freeze but if test
capacity exists sometimes additional bugs can be added.
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-0934.html