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): autofs-4.1.1-3 How reproducible: Always 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 Actual Results: The mount is not made (running ls on a directory that should be automounted gives "no such file or directory"). Expected Results: The directory should be mounted with the given options. Additional info: 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 /var/log/messages? Thanks.
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 preformed.
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? --timeout=60,hard,intr,nodev,nosuid,nobrowse I needed to take out both quota and nobrowse for this to work in my environment.
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 ers=3,proto=tcp 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 wildcard mounts. 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. Thanks!