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: attempting to mount entry
Oct 4 19:45:49 phobos modprobe: modprobe: Can't locate module bind
Oct 4 19:45:49 phobos automount: >> 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
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
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 "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.
ln -s /usr/src/linux/include/linux/limits.h .
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:
Then on each machine:
rpm -U --oldpackage autofs-3.1.4-4.i386.rpm && /bin/mv /etc/auto.master.rpmsave
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.
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]"