The auto.net script that comes with autofs5 is broken
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
autofs5 (Fedora) |
Fix Released
|
Medium
|
|||
autofs5 (Ubuntu) |
New
|
Medium
|
Unassigned |
Bug Description
A long time ago I reported a bug in the autofs package: https:/
That bug was fixed, but now I've discovered that the same bug still exists in the autofs5 package. Please see the above bug for the issue and the fix (I applied the fix by hand to my current system and it did solve the problem). Without this fix, the autofs /net map is simply non-functioning in many common Enterprise environments.
~$ dpkg -S auto.net
autofs5: /usr/share/
~$ lsb_release -r -d
Description: Ubuntu 10.10
Release: 10.10
~$ apt-cache policy autofs5
autofs5:
Installed: 5.0.5-0ubuntu2.1
Candidate: 5.0.5-0ubuntu2.1
Version table:
*** 5.0.5-0ubuntu2.1 0
500 http://
100 /var/lib/
5.0.5-0ubuntu2 0
500 http://
Changed in autofs5 (Ubuntu): | |
importance: | Undecided → Medium |
Changed in autofs5 (Fedora): | |
importance: | Unknown → Medium |
status: | Unknown → Fix Released |
Created attachment 555563
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/ . dev01/tools/ .: No such file or directory
ls: cannot access /net/snap-
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 <email address hidden> 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.