On Thu, 23 Sep 2004, Jim Carter wrote: > There's an ambiguity whether you're going to stat the mount point with > nothing mounted on it, or the referent of the mount. Since the automounter > is involved, the mount points could exist without referents, depending on > the version you're using and what options you've set for ghost mounts > (browsing). The automounter *should* finish the mount before releasing the > thread to do the stat, but... If you stat /home/$user/. then the filename > resolution code has to actually read the referent directory and look up "." > in it, resolving the ambiguity.
I see. > > checking mounts > > 10.201.1.10:/VOL1/Arb/94AZAJMI on /home/94azajmi type nfs > (rw,nfsvers=2,hard,intr,addr=X.X.X.X) > > The script mentioned further on (programmatic automount map?) changes the > loginID to upper case, because that is what is on the Novell system, right? Well, we don't know the case for the last component. So, the path can be either 10.201.1.10:/VOL1/Arb/94AZAJMI or 10.201.1.10:/VOL1/Arb/94azajmi. Therefore, tl-nds-mountpath tries to mount the one with uppercase, and if that fails, it returns the lowercase variant. > "mount | grep $user" and "grep $user /proc/mounts" normally give the > same basic answers (a few options appear only in /etc/mtab), and if > there were a difference between them, it might be a clue. I didn't check this yesterday, but we have checked it earlier without finding any differences (as far as I can remember). > > I've noticed one very interesting thing: Each time I do a "umount > > /home/94azajmi", this ends up in the system logg: > > > > Sep 23 15:03:38 foobar last message repeated 3 times > > Sep 23 15:03:42 foobar automount[1565]: attempting to mount > entry /home/94azajmi > > Sep 23 15:03:42 foobar automount[6586]: >> mount: > 10.201.1.10:/VOL1/Arb/94azajmi failed, reason given by server: No such > file or directory > > The server did not lie, right? /VOL1/Arb/94AZAJMI is on the server, not > /VOL1/Arb/94azajmi. Is it possible that there are *two* automount maps, > one with the programmatic case conversion and one maybe a simple file map > with a wildcard? No. The auto.master contains only one map, the one I sent in my original posting. > > tl-nds-mountpath does a test-mount (in another > > directory) before returning the mount path. > > Maybe the message above from process 6586 is the test mount, which needed > case conversion and didn't get it. As I understand it, pid 1565 is the automount process for /home, while process 6586 is the forked-off child: the programmatic map tl-nds-mountpath. > > Of course, the question is why a umount triggers a mount in the first > > place... > > Let me guess: automount has to consult the map to know the exact hostname > and options used to mount the filesystem, some of which are needed for the > unmount. (Well, I always do "umount /mount/point" and it works, but maybe > the automounter needs to do more, such as finding and clearing an entry in > the list of filesystems it is responsible for.) In your case, the map is > programmatic and includes the test mount. But under obscure circumstances > the necessary case conversion isn't happening. Can anyone confirm that the automounter actually may call the programmatic map upon umount? If so, can the programmatic map detect that a umount is happening, rather than a mount? > Things would be a lot easier if you didn't have to do the test mount. > Maybe do the Novell equivalent of a YP or Hesiod lookup so you know the > right loginID without having to do any mounts. Actually, the problem is not the loginID, but the case of the directory to mount. With home directories, the last component of the mount path is the same as the loginID, but this might not be true for other exports, such as common data areas. Also, the case of the loginID (as returned from NDS) might not be the same as the case of the actual directory. Future versions of tl-nds-mountpath will speak the mount protocol directly to verify that we have found the correct case of all components. I'm still interested to know if a programmatic map might be called upon umount, though. -- Peter �strand Chief Developer Cendio www.thinlinc.com Teknikringen 3 www.cendio.se 583 30 Link�ping Phone: +46-13-21 46 00 _______________________________________________ autofs mailing list [EMAIL PROTECTED] http://linux.kernel.org/mailman/listinfo/autofs
