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.
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.
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 | \
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