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 782169 - The /net automount map fails for some export styles
Summary: The /net automount map fails for some export styles
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: autofs
Version: 6.2
Hardware: All
OS: Linux
medium
medium
Target Milestone: rc
: ---
Assignee: Ian Kent
QA Contact: yanfu,wang
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2012-01-16 17:45 UTC by Paul Smith
Modified: 2018-11-28 21:11 UTC (History)
3 users (show)

Fixed In Version: autofs-5.0.5-42
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2012-06-20 14:46:51 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)
Fix auto.net to ignore duplicate export partitions (451 bytes, patch)
2012-01-16 17:45 UTC, Paul Smith 		no flags Details | Diff
View All


Links
System ID Private Priority Status Summary Last Updated
Launchpad 111612 0 None None None Never
Launchpad 912030 0 None None None Never
Red Hat Product Errata RHBA-2012:0951 0 normal SHIPPED_LIVE autofs bug fix and enhancement update 2012-06-19 20:59:38 UTC

Description Paul Smith 2012-01-16 17:45:00 UTC 
Created attachment 555563 [details]
Fix auto.net to ignore duplicate export partitions

Description of problem:

For NFS servers which export the same partition with different options (for example, a partition might be exported to one system with root privileges enabled and all other systems with root squash enabled--this is a common scenario in Enterprise environments), the /net automount map fails to find ANY exported partitions.

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

This issue is present in all versions of autofs 4 and autofs 5 that I've checked.

How reproducible:

100%.

Steps to Reproduce:
1. Configure an NFS server to export the same partition in two different ways and export them.  When you run showmount -e against that host you should see multiple entries like this:
~$ showmount -e snap-dev01
Export list for snap-dev01:
/user     172.0.0.0/8
/tools    172.0.0.0/8
/projects 172.0.0.0/8
/user     devtools
/tools    devtools
/projects devtools
The server doesn't have to be running Red Hat (or even Linux); it's not a server problem.

2. On a client (running Red Hat), attempt to access one of these partitions through the /net automount map as it comes configured by default:

  
Actual results:

~$ ls /net/snap-dev01/tools/.
ls: cannot access /net/snap-dev01/tools/.: No such file or directory

Expected results:

~$ ls /net/snap-dev01/tools/.
bin     etc     info    man     sbin
dist    include lib     share   tmp

Additional info:

I filed a bug against Ubuntu autofs4 back in 2007 and they did fix it there:

https://bugs.launchpad.net/ubuntu/+source/autofs/+bug/111612

I've recently discovered that this problem still exists in the latest Ubuntu for autofs5 and I filed a bug there as well:

https://bugs.launchpad.net/ubuntu/+source/autofs5/+bug/912030

The bug is in the default auto.net handling script that comes with autofs, so I also sent a bug report upstream to the autofs maintainers at autofs.org but unfortunately that mailing list doesn't appear to be archived anywhere anymore so I can't give you a link.

I've attached my patch to fix the problem here as well.
Comment 3 yanfu,wang 2012-05-09 03:34:31 UTC 
From Ian's advice:
This is a change to the auto.net script which is not our recommended way to use the hosts map. So, I think sanity only is sufficient for this one. 
The old /etc/auto.net is below:
$SHOWMOUNT | LC_ALL=C sort -k 1 | \
Confirm the /etc/auto.net in new autofs-5.0.5-54.el6:
$SHOWMOUNT | LC_ALL=C cut -d' ' -f1 | LC_ALL=C sort -u | \
Comment 4 errata-xmlrpc 2012-06-20 14:46:51 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.

http://rhn.redhat.com/errata/RHBA-2012-0951.html
Note You need to log in before you can comment on or make changes to this bug.