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 /nfs file:/etc/auto.nfs Here is auto.nfs: * -fstype=nfs,-Dhost=&,-Dprefix=/& file:/etc/auto.nfs.sub And here is auto.nfs.sub: * ${host}:${prefix}/& 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[7863]: mount(nfs): host file: lookup failure Oct 27 16:36:44 $HOSTNAME automount[7863]: 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): autofs-4.1.3-12 How reproducible: Always 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. Additional info: Worked prior to the autofs update of 10-16.
Oh, also, changing auto.nfs to say '-fstype=autofs' does not resolve the issue.
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 "file."
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) auto.nfs * -fstype=nfs &:/&
http://www.linux-consulting.com/Amd_AutoFS/autofs-5.html 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 foo:/bar/baz/