Bug 18354

Summary:	autofs fails on first access of a local filesystem mount
Product:	[Retired] Red Hat Linux	Reporter:	Need Real Name <graeme>
Component:	autofs	Assignee:	Nalin Dahyabhai <nalin>
Status:	CLOSED CURRENTRELEASE	QA Contact:
Severity:	medium	Docs Contact:
Priority:	medium
Version:	7.0	CC:	ajr, aoliva, bme, dr, j, leif, sh
Target Milestone:	---
Target Release:	---
Hardware:	i386
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2004-04-14 22:22:50 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Need Real Name 2000-10-04 19:13:21 UTC

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.

Comment 1 Nalin Dahyabhai 2000-10-04 23:05:46 UTC

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 09:16:13 UTC

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 14:03:27 UTC

Okay, we'll have to look deeper into this for 2.2 kernels, then.

Comment 4 Need Real Name 2000-11-09 10:09:35 UTC

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

Comment 5 Jason Tibbitts 2000-11-16 18:07:26 UTC

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 18:25:41 UTC

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

Comment 7 Need Real Name 2001-01-28 00:05:08 UTC

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]"