Bug 120530 - autofs fails to work if options are specified in auto.master
autofs fails to work if options are specified in auto.master
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: autofs (Show other bugs)
rawhide
x86_64 Linux
medium Severity medium
: ---
: ---
Assigned To: Jeffrey Moyer
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2004-04-09 17:14 EDT by Carlos A. Villegas
Modified: 2007-11-30 17:10 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-04-11 16:09:47 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
sample /etc/auto.master file with comments to make the bug more clear (339 bytes, text/plain)
2004-04-09 17:19 EDT, Carlos A. Villegas
no flags Details
sample workaround script for a NIS auto.home map (/etc/auto.home) (132 bytes, text/plain)
2004-04-09 17:20 EDT, Carlos A. Villegas
no flags Details
logs for use of options in /etc/auto.master (1.20 KB, text/plain)
2004-04-14 16:39 EDT, Carlos A. Villegas
no flags Details

  None (edit)
Description Carlos A. Villegas 2004-04-09 17:14:57 EDT
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).
Comment 1 Carlos A. Villegas 2004-04-09 17:19:20 EDT
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.
Comment 2 Carlos A. Villegas 2004-04-09 17:20:35 EDT
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.
Comment 3 Jeffrey Moyer 2004-04-14 11:28:22 EDT
Could you please post the logs for the failure case, found in
/var/log/messages?  Thanks.
Comment 4 Carlos A. Villegas 2004-04-14 16:39:33 EDT
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.
Comment 5 Carlos A. Villegas 2004-04-14 16:44:00 EDT
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).
Comment 6 Jeffrey Moyer 2004-04-14 16:55:18 EDT
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.
Comment 7 Carlos A. Villegas 2004-05-03 16:16:31 EDT
 
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... 
 
Comment 8 Chuck Berg 2004-05-05 12:16:00 EDT
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.
Comment 9 Jeffrey Moyer 2004-05-05 12:51:32 EDT
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?
Comment 10 Jeffrey Moyer 2005-04-11 16:09:47 EDT
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!

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