Bug 782169 - The /net automount map fails for some export styles
The /net automount map fails for some export styles
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: autofs (Show other bugs)
All Linux
medium Severity medium
: rc
: ---
Assigned To: Ian Kent
Depends On:
  Show dependency treegraph
Reported: 2012-01-16 12:45 EST by Paul Smith
Modified: 2012-06-20 10:46 EDT (History)
3 users (show)

See Also:
Fixed In Version: autofs-5.0.5-42
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2012-06-20 10:46:51 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

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

External Trackers
Tracker ID Priority Status Summary Last Updated
Launchpad 111612 None None None Never
Launchpad 912030 None None None Never

  None (edit)
Description Paul Smith 2012-01-16 12:45:00 EST
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:


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     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:


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


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@vger.kernel.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-08 23:34:31 EDT
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 10:46:51 EDT
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.


Note You need to log in before you can comment on or make changes to this bug.