Bugzilla will be upgraded to version 5.0. The upgrade date is tentatively scheduled for 2 December 2018, pending final testing and feedback.
Bug 18354 - autofs fails on first access of a local filesystem mount
autofs fails on first access of a local filesystem mount
Product: Red Hat Linux
Classification: Retired
Component: autofs (Show other bugs)
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Nalin Dahyabhai
Depends On:
  Show dependency treegraph
Reported: 2000-10-04 15:13 EDT by Need Real Name
Modified: 2007-04-18 12:28 EDT (History)
7 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2004-04-14 18:22:50 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Need Real Name 2000-10-04 15:13:21 EDT
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
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
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 bug.
Comment 1 Nalin Dahyabhai 2000-10-04 19:05:46 EDT
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?
Comment 2 Need Real Name 2000-10-05 05:16:13 EDT
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.
Comment 3 Nalin Dahyabhai 2000-10-06 10:03:27 EDT
Okay, we'll have to look deeper into this for 2.2 kernels, then.
Comment 4 Need Real Name 2000-11-09 05:09:35 EST
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 ..
make install
Comment 5 Jason Tibbitts 2000-11-16 13:07:26 EST
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.
Comment 6 Need Real Name 2000-11-16 13:25:41 EST
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.

Comment 7 Need Real Name 2001-01-27 19:05:08 EST
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]"

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