Bugzilla – Bug 118902
autofs4 auto.net unexpected bahaviour
Last modified: 2006-11-14 15:25:45 UTC
How to reproduce: You need a NFS server exporting only one Filesystem, and a NFS server exporting more than one Filesystem (does not matter which OS the NFS server is). E.g. /usr/local and /home (containing directories user1, user2, ...) On the 10.0 machine: Uncomment line containing /net in /etc/auto.master Start autofs cd /net/<nfs-server> ls If <nfs-server> exports more than 1 filesystem, you can see the exported FSs, e.g. home, usr/local If <nfs-server> exports exactly 1 filesystem, e.g. home, you see the directories in home (user1, user2,...), not home as in the case above.
Sounds like this was intended, because it makes sense ;) The maintainer should decide anyway.
isn't feature of autofs? (reassigned to maintainer)
(In reply to comment #1) > Sounds like this was intended, because it makes sense ;) > The maintainer should decide anyway. In SL 9.3 it showed /net/<nfs-server>/home and did nut suppress it.
Using /etc/auto.net from 9.3 does not help.
autofs4 seems to mix up hostname and filesystem. wptx82 exports only /scratch. I did: cd /net/wptx82 and immediately, I got in the log file: Oct 14 11:11:06 linux automount[23290]: mount(nfs): host /scratch: lookup failure If I type ls, I do not see scratch, as expected, but the contents of scratch.
Same in final release
I also get the following error messages: Nov 4 18:05:40 wptx85 automount[8086]: mount(nfs): host /scratch: lookup failure
any progress?
Closed due to inactivity.
Still the same problem in 10.1. Who is inactive by the way? ;-)
The bug was inactive, sorry :) Thanks for letting us know it's still present...
I tend to agree that this behavior is problematic. The behavior on the client shouldn't change due to the server administrator adding or removing exports. I'm reluctant to change existing behavior, but since adding an export on the server does the same thing, I suppose it's not too big a problem.
Hi Andreas - I've tracked down the cause of the behavior you're seeing, and it is intended. We shipped autofs v3 in SUSE LINUX 9.3, but updated it to v4 in SUSE LINUX 10.0. This version was used in 10.1 as well. V4 introduced multi-mounts, which allow you to define multiple directories for normal autofs mounts. It's essentially the same behavior you expect with auto.net, but it can be explicitly defined for regular automount maps. The code autodetects if it's a single mount or a new multi-mount. Unfortunately, a side effect of that autodetection is the bug you've reported. In order to preserve that behavior, and fix the bug you're seeing, I've introduced a -multi option that forces a particular mapping to use the multi behavior. I've also added this option to the auto.net script. This yields consistent behavior under /net, regardless of the number of exports a particular server has. I've posted packages with this fix for testing at ftp://ftp.suse.com/pub/people/jeffm/suse/testpkgs/118902/ Please choose the correct package for your platform, and confirm that it corrects the problem for you. You will have to use the /etc/auto.net.rpmnew that is included in the package for the fix to take effect. If you still experience the problem with it looking up the export name as a hostname, please let me know.
There is no /etc/auto.net.rpmnew, but the /etc/auto.net works great on i386 and x86_64.
Ok. That makes sense. RPM treats it as a config file it shouldn't replace if you've changed it. I had changed mine for testing, so it didn't replace it. If you didn't change yours, it wouldn't have. I'll commit the change, and it will be included in our next release.
(In reply to comment #1) > Sounds like this was intended, because it makes sense ;) A late reply: The problem is that the similar autofs on HP-UX does it differently, and the autofs maintainer said it's a bug that has been fixed long ago. However it doesn't look like it. Here's the message (Ian Kent <raven@themaw.net>): On Tue, 2006-11-14 at 08:24 +0100, Ulrich Windl wrote: > Hi, > > I have a problem where autofs (Novell SLES10, autofs-4.1.4-23.4) discards the > first and only directory for an NFS mount; for two directories the thing seems to > work OK. I've browsed the sources, but couldn't easily find the problem. I'm sure this problem has been resolved long ago but I can't remember. It may be the check for whether an entry is a multi-mount or not that is at fault but I have no idea what patches are included in SLES10. This pre-analysis is really something that the downstream package maintainer needs to do so that I can hopefully make some sense of what may or may not be included in the package already. You might check to see if http://www.kernel.org/pub/linux/daemons/autofs/v4/autofs-4.1.4-multi-parse-fix.patch has been applied. > > The problem is that "server:/foo" which should be mounted to "/net/server/foo" is > actually mounted to "/net/server" (with "foo's content" in "server") > > Here's my trace: > > automount[24703]: lookup(program): server -> -fstype=nfs,hard,intr,nodev,nosuid > /foo server:/foo > automount[24703]: parse(sun): core of entry: > options=fstype=nfs,hard,intr,nodev,nosuid, loc=/foo server:/foo > automount[24703]: parse(sun): mounting root /net, mountpoint server, what /foo > server:/foo, fstype nfs, options hard,intr,nodev,nosuid > Nov 9 16:56:47 rksapas03 automount[24703]: mount(nfs): root=/net name=server > what=/foo server:/foo, fstype=nfs, options=hard,intr,nodev,nosuid > automount[24703]: mount(nfs): nfs options="hard,intr,nodev,nosuid", nosymlink=0, > ro=0 > automount[24703]: mount(nfs): host /foo: lookup failure > automount[24703]: mount(nfs): winner = server local = 0 > automount[24703]: mount(nfs): from /foo server:/foo elected server:/foo > automount[24703]: mount(nfs): calling mkdir_path /net/server > automount[24703]: mount(nfs): calling mount -t nfs -s -o hard,intr,nodev,nosuid > server:/foo /net/server > automount[24703]: mount(nfs): mounted server:/foo on /net/server > > > (Actual names replaced for clarity) > > Regards, > Ulrich