autofs will fail on the first attempt to access a filesystem which is local to the machine. In /var/log/messages there appears the following: Oct 4 19:45:49 phobos automount[1078]: attempting to mount entry /home/graeme Oct 4 19:45:49 phobos modprobe: modprobe: Can't locate module bind Oct 4 19:45:49 phobos automount[1326]: >> mount: fs type bind not supported by kernel However, even though modprobe suffers this bizarre failure the correct soft link is created, so subsequent attempts to access the file system work: root of phobos:~# ypmatch graeme auto.home phobos:/export3/home/& root of phobos:~# ls /home/graeme ls: /home/graeme: No such file or directory root of phobos:~# ls /home/graeme Mail dept_it include misc plasma solar texmf News doc iraf ns_imap public_html starlink tmp RealPlayer7 fiona itsig nsmail redhat statmech bin hessi mail office52 roof_20000827.sdw teaching Mounts which are on remote machines function correctly: root of phobos:~# ypmatch gail auto.home deimos:/export2/home/& root of phobos:~# ls /home/gail Xrootenv.0 app.tex bruzual nsmail photom.ps xit Switching the bind module off by adding "alias bind off" to /etc/modules.conf gets rid of the "modprobe: Can't locate module bind" message, but the "fs type bind not supported by kernel" remains, as does the bug.
The "bind" filesystem type was introduced in late 2.3-series kernels, and autofs attempts to take advantage of this to make a more transparent NFS mount. It's possible there's some timing issue involved, since it appears to be falling back to the older method and eventually creating a symlink, which is what it's always done for 2.2 kernels. If you use "ls /home/graeme", pause for a few seconds, and then "ls /home", does the "graeme" symbolic link get created correctly?
Yes, doing "ls /home/graeme" produces the bug, but also creates the correct symlink. That seems to be why subsequent attempts to access the filesystem succeed. So, indeed there seems to be a timing issue: autofs seems to produce the error (via trying the bind filesystem), then fix it up through the symlink.
Okay, we'll have to look deeper into this for 2.2 kernels, then.
While the correct solution to this must be to upgrade to autofs-3.1.7 (thanks Nalin), downgrading to autofs-3.1.4 worked for me (RedHat 7.0, almost everything installed). Hope this helps. Tony Robinson wget ftp://ftp.kernel.org/pub/linux/daemons/autofs/autofs-3.1.4 cd autofs-3.1.4/include ln -s /usr/src/linux/include/linux/limits.h . cd .. ./configure make make install
Is there an official RPM that fixes this? Rawhide only has 3.1.5-6 and it won't install due to library dependencies anyway. This really is more of a problem than it might seem: users having odd problems because their home directories are occasionally nonexistent, license managers failing because their keys aren't there when they look for them, the web server reporting errors for pages on the first access, etc. It makes the whole system look flaky.
I didn't post this before for fear of talking to myself, but the solution I ended up implementing was: ftp://ftp.redhat.com/pub/redhat/redhat-6.2/i386/RedHat/RPMS/autofs-3.1.4-4.i386.rpm Then on each machine: rpm -U --oldpackage autofs-3.1.4-4.i386.rpm && /bin/mv /etc/auto.master.rpmsave /etc/auto.master Or, in summary, the redhat-6.2 package seems to install and work fine. I agree with you on the severity - I lost man-days and valuable data as cron scripts mysteriously failed. Tony
If you install the 6.2 autofs and reinstall your 7.0 auto.master (as suggested by ajr), beware that the 7.0 auto.master has /misc /etc/auto.misc --timeout=60 and the 6.2 /etc/rc.d/init.d/autofs does not handle the "=". You must either replace the above line by /misc /etc/auto.misc --timeout 60 or change the 6.2 autofs to look for "[ \t=]" rather than "[ \t]"