Description of problem: When logging into a system using ssh, that user's home directory is only partially mounted from the NFS server. By partially, I mean that nearly all files and directories normally in the home dir are missing from a directory listing, nor do they appear when read/opened etc. If a directory happens to be present, then the tree under that directory is also present. The systems have been using YP to obtain auto.master and auto.home for 7 years, this is the first time I've seen this behavior. The problem first appeared on my 3 systems running Fedora Core 5, following updates on or around 20 June 2006. I've seen the problem once on systems running rawhide. I'm trying now to downgrade to earlier autofs releases for FC5 to see if that helps. # ypcat auto.master auto.home --timeout 60 # ypcat auto.home -udp,hard,intr myserver:/home/& When the automounter works, I see messages such as this in /var/log/messages on the NFS server(humbolt): Jun 19 09:31:27 humbolt rpc.mountd: authenticated mount request from 10.9.160.142:682 for /home/mdomsch (/home) No problem there. When it fails, I see these messages: Jun 20 15:27:47 humbolt rpc.mountd: authenticated mount request from 10.9.160.247:705 for /home/mdomsch/.hushlogin (/home) Jun 20 15:27:47 humbolt rpc.mountd: can't stat exported dir (Note: it's doing something weird trying to mount files not necessarily dirs. This could explain why, when it fails, I see the directories in the mount that would be expected, but can't see the files in the mounted directory). /home/mdomsch/.hushlogin: No such file or directory Jun 20 15:27:47 humbolt rpc.mountd: authenticated mount request from 10.9.160.247:707 for /home/mdomsch/.hushlogin (/home) Jun 20 15:27:47 humbolt rpc.mountd: can't stat exported dir /home/mdomsch/.hushlogin: No such file or directory Jun 20 15:27:48 humbolt rpc.mountd: authenticated mount request from 10.9.160.247:713 for /home/mdomsch/.inputrc (/home) Jun 20 15:27:48 humbolt rpc.mountd: can't stat exported dir /home/mdomsch/.inputrc: No such file or directory Jun 20 15:27:48 humbolt rpc.mountd: authenticated mount request from 10.9.160.247:715 for /home/mdomsch/.dircolors (/home) Jun 20 15:27:48 humbolt rpc.mountd: can't stat exported dir /home/mdomsch/.dircolors: No such file or directory Jun 20 15:27:48 humbolt rpc.mountd: authenticated mount request from 10.9.160.247:717 for /home/mdomsch/.dircolors.xterm (/home) Jun 20 15:27:48 humbolt rpc.mountd: can't stat exported dir /home/mdomsch/.dircolors.xterm: No such file or directory Jun 20 15:27:48 humbolt rpc.mountd: authenticated mount request from 10.9.160.247:719 for /home/mdomsch/.dir_colors (/home) Jun 20 15:27:48 humbolt rpc.mountd: can't stat exported dir /home/mdomsch/.dir_colors: No such file or directory Jun 20 15:27:48 humbolt rpc.mountd: authenticated mount request from 10.9.160.247:721 for /home/mdomsch/.dir_colors.xterm (/home) Jun 20 15:27:48 humbolt rpc.mountd: can't stat exported dir /home/mdomsch/.dir_colors.xterm: No such file or directory Jun 20 15:27:48 humbolt rpc.mountd: authenticated mount request from 10.9.160.247:732 for /home/mdomsch/.i18n (/home) Jun 20 15:27:48 humbolt rpc.mountd: can't stat exported dir /home/mdomsch/.i18n: No such file or directory Jun 20 15:27:48 humbolt rpc.mountd: authenticated mount request from 10.9.160.247:737 for /home/mdomsch/.bash_profile (/home) Jun 20 15:27:48 humbolt rpc.mountd: authenticated mount request from 10.9.160.247:738 for /home/mdomsch/.bash_login (/home) Version-Release number of selected component (if applicable): autofs-4.1.4-27 How reproducible: often, though certainly not every time. Clients so far have to be FC5 or rawhide with fairly recent updates.
Take a look at http://people.redhat.com/jmoyer, under the section "Filing bug reports." If you could provide us with the debug logs as outlined there, it would help a great deal. Also, when getting these failures under 4.1.4-27, what kernel you are using? Thanks!
kernel 2.6.16-1.2133_FC5 x86_64 autofs-4.1.4-27.x86_64.rpm /etc/nsswitch: passwd: files nis shadow: files nis group: files nis hosts: files nis dns bootparams: nisplus [NOTFOUND=return] files ethers: files netmasks: files networks: files protocols: files nis rpc: files services: files nis netgroup: files nis publickey: nisplus automount: files nis aliases: files nisplus /etc/sysconfig/autofs is the default file (comments trimmed): LOCALOPTIONS="" DAEMONOPTIONS="--timeout=60" UNDERSCORETODOT=1 DISABLE_DIRECT=1 DAEMON_EXIT_WAIT=10 LDAPAUTOMASTER="" I'll collect some debug logs and post those separately.
(In reply to comment #0) > > # ypcat auto.master > auto.home --timeout 60 > > # ypcat auto.home > -udp,hard,intr myserver:/home/& When you do these could you add the -k option to ypcat so we can see the yp map key as well please. Ian
(In reply to comment #0) > The problem first appeared on my 3 systems running Fedora Core 5, following > updates on or around 20 June 2006. I've seen the problem once on systems > running rawhide. I'm trying now to downgrade to earlier autofs releases for FC5 > to see if that helps. Yes. I've found a bug in a patch that I applied recently. The bug was present from autofs-4.1.4-25 which reached the RedHat mirror on the 11th June so the dates almost match. From the information provided so far I can't tell if this is the problem you are seeing but I'll post the patch so you can check. The error is present in FC-4, FC-5 and Rawhide.
Created attachment 131408 [details] Correction to previous patch for space handling in get_best_mount
(In reply to comment #5) > Created an attachment (id=131408) [edit] > Correction to previous patch for space handling in get_best_mount > I've pushed a test rpm with this patch, autofs-4.1.4-29. It can be found in the appropriate architecture directory at: http://download.fedora.redhat.com/pub/fedora/linux/core/updates/testing/5 Could you test this and see if it helps please.
No joy. 4.1.4-29 still occasionally fails in the same manner. I had ensured that the previous versions had been stopped cleanly before installing and starting the new version. As for the ypcats, here's the data: $ ypcat -k auto.master /home auto.home --timeout 60 $ ypcat -k auto.home * -udp,hard,intr hb.linuxdev.us.dell.com:/home/&
(In reply to comment #7) > No joy. 4.1.4-29 still occasionally fails in the same manner. I had ensured > that the previous versions had been stopped cleanly before installing and > starting the new version. > > As for the ypcats, here's the data: > > $ ypcat -k auto.master > /home auto.home --timeout 60 > $ ypcat -k auto.home > * -udp,hard,intr hb.linuxdev.us.dell.com:/home/& > OK. I'll keep looking.
(In reply to comment #2) > > I'll collect some debug logs and post those separately. Hi Matt, Have you been able to collect any debug logs? Ian
I haven't seen this issue in quite a while, though I had turned off autofs for a while too. I'll close this now as WORKSFORME, and re-open if it turns up again.