From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; Linux i686; U) Opera 7.21 [en]
Description of problem:
If options are used in /etc/auto.master, the automount will fail
(automount will run on that directory, but the mounts will never be
made). killing automount and removing the options from /etc/auto.
master will make it work (but with default options). It also happens
in i386 platform (and i686...).
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Add an entry to /etc/auto.master with options
2. start autofs
3. try to get one of the automounted dirs
The mount is not made (running ls on a directory that should be
automounted gives "no such file or directory").
The directory should be mounted with the given options.
There is a workaround to this and is to create a script to give the
entry and options. For some reason it works there, but not on auto.
master... I'm attaching a sample /etc/auto.master, and a sample
script for this workaround (using /home as an example).
Created attachment 99285 [details]
sample /etc/auto.master file with comments to make the bug more clear
This files has comments to clarify the bug, it implements part of the
workaround I mention in the bug report.
Created attachment 99286 [details]
sample workaround script for a NIS auto.home map (/etc/auto.home)
This script is part 2 of 2 of the workaround described in the bug report.
Could you please post the logs for the failure case, found in
Created attachment 99427 [details]
logs for use of options in /etc/auto.master
I'm using a custom syslog.conf, so I chased all the autofs related entries from
all my logs and merged them by hand for a simple case (so they might be a
little messed up, but relatively accurate), I commented the case using
logger(1), I left those comments in for easier correlation with the actions I
While gathering the logs, I noticed that the options are also ignored
for the workaround described (I tried removing quota, and placing a
suid executable in my home directory, it was still executed with
suid, eventhough I have nosuid as an option).
Okay, it is currently unclear to me what configuration you are testing
with. Are these the options you are passing?
I needed to take out both quota and nobrowse for this to work in my
Sorry for the delay. Yes, I was in fact using in auto.master, as soon as nobrowse was
removed, everything worked as expected, if I remember correctly the nobrowse did
nothing, and was there only for compatibility with solaris (it has been there for a long
time), is it going away? (just curious).
Please consider this closed. And sorry for the waste of time...
Lack of compatibility with Solaris is a problem. A lot of people using
an auto.master NIS map to configure their automounter are in a
primarily Solaris environment.
In my case, mount options like this do not work:
/home auto.home -vers=3,proto=tcp
This is perfectly valid syntax on Solaris. But the autofs init script
(FC2test3, or RHEL3) runs this:
/usr/sbin/automount --timeout=60 --verbose /home yp auto.home
I've just hacked the init script so that it works in my environment. I
don't have enough different auto.masters to test with to know what
would work as a general fix.
Well, with regards to the nobrowse option, autofs for linux never
actually dealt with that before (since it didn't support browsing).
It would pass the options on to mount, which would then ignore
anything it didn't recognize. Under solaris, I think it was common
practice to use the nobrowse option for mounts such as /net or
The newer version of util-linux that we ship doesn't ignore the option
as it should. This should get fixed in short order, I hope.
As for comment #8, it is arguable whether this is a compatibility
issue with automount or nfs/mount syntax. The equivalent Linux nfs
mount option is nfsvers=3. Though, the script is definitely buggy in
that it converts the -v to --verbose, and saves the rest as mount options.
When mount gets fixed, your -vers=3 parameter will be ignored. The
default behaviour should be to autonegotiate the highest version
number supported between client and server. Would this be acceptable?
All issues listed in this bug should be addressed in the current release. If
you find that any has not been addressed, please open a new bug.