From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7) Gecko/20040616
Description of problem:
Here is /etc/auto.master:
# mountpoint map options
Here is auto.nfs:
* -fstype=nfs,-Dhost=&,-Dprefix=/& file:/etc/auto.nfs.sub
And here is auto.nfs.sub:
This is a common set of config files that I inherited.
The most recent autofs update renders the automount demon
unable to parse those files correctly.
Oct 27 16:36:44 $HOSTNAME automount: mount(nfs): host file:
Oct 27 16:36:44 $HOSTNAME automount: failed to mount /nfs/$SERVER
Tcpdump shows that automount does not attempt to resolve a hostname.
It doesn't get that far.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Put the files above. restart autofs.
2. Do "ls /nfs/server/mountpoint" for any known value of
server and mountpoint in your local net.
3. Check the logs afterwards.
Actual Results: Didn't mount. Left error message in logs.
Expected Results: SHould have mounted an NFS share.
Worked prior to the autofs update of 10-16.
Oh, also, changing auto.nfs to say '-fstype=autofs' does not resolve
Looking at the source now, I see that the error is in mount_nfs.c:
error(MODPREFIX "host %s: lookup failure", p). autofs misinterprets
the directive in auto.nfs to mean we should look for the host named
This script should not have worked in the past. In auto.nfs, 'file:'
should always be interpreted as a machine name. Which is why the map
fails. You can change auto.nfs the following, and I think it will
solve your problem. (There is no need for the auto.nfs.sub)
* -fstype=nfs &:/&
The autofs community seems to disagree. The way you're recommending I
do it, autofs will parse an attempt at looking at
/nfs/foo/bar/baz/quux as requiring a mount of foo:/bar instead of