Red Hat Bugzilla – Bug 222777
Automount fails for home directory
Last modified: 2007-11-30 17:11:53 EST
Description of problem:
Automounted home directory fails to mount at login.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1.Try logging into the system.
ls -dZ /home
drwxr-xr-x root root system_u:object_r:home_root_t /home
The three other systems that work show:
drwxr-xr-x root root system_u:object_r:autofs_t /home
I did touch /.autorelabel and reboot but got the same results.
I'm getting rummy from too much banging on the keyboard. I just dropped to
permissive and the automount still fails. But I do not know whether I would need
to restart autofs or do something else.
After several more hours of testing I do not believe the issue I'm having with
the automounter is related to labeling. But it is still not working and I have
had several other very good system administrators go over the checks I have done
and look at the issue but we still have not found the root cause of the problem.
After installing audit and retesting I see this information in the
type=USER_LOGIN msg=audit(1169096567.183:84): user pid=3629 uid=0 auid=429496729
5 subj=system_u:system_r:unconfined_t:s0-s0:c0.c1023 msg='acct=dhighley: exe="/u
sr/sbin/sshd" (hostname=?, addr=10.2.2.7, terminal=sshd res=failed)'
I get this information from /var/log/messages:
Jan 17 20:18:43 redwood automount: mount_autofs_indirect: failed
to read map for /home
Jan 17 20:18:43 redwood automount: handle_mounts: mount of /home
Jan 17 20:18:43 redwood automount: master_do_mount: failed to st
Switching ownership to autofs in order to get their imput on this bugzilla.
Please provide your autofs maps. If they live in NIS, be sure to pass the "-k"
option to ypcat. We'll also need to see the automount: line from
That first log message from the automounter indicates that automount was not
able to even read your map file for the mount point /home. Are you sure *that*
is labeled properly?
Taken from the client that has the issue. But I do not think this is an NIS
issue. If you look at the /var/log/audit/audit.log information above you will
find that the /usr/sbin/sshd entry has the hostname=?. Note, that all map
information, local files, and DNS show no problems. Login completes if I type in
a password and the automounter maps an empty home directory for the user. I can
manually mount the NFS share to the automounter created location. Selinux is in
enforcing mode and iptables is disabled on the client. I have tested with
Selinux in permissive mode and it made no difference.
-bash-3.1$ ypcat -k auto.master
-bash-3.1$ ypcat -k auto.home
-bash-3.1$ ypmatch -k spruce hosts
spruce 10.2.2.2 spruce.highley-recommended.com spruce internal ftp-i
hosts: files dns nis
automount: files nis
-bash-3.1$ cat /etc/hosts
# Do not remove the following line, or various programs
# that require network functionality will fail.
127.0.0.1 localhost.localdomain localhost
::1 localhost.localdomain localhost
10.2.2.9 redwood.highley-recommended.com redwood
-bash-3.1$ cat /etc/auto.master
# $Id: auto.master,v 1.4 2005/01/04 14:36:54 raven Exp $
# Sample auto.master file
# This is an automounter map and it has the following format
# key [ -mount-options-separated-by-comma ] location
# For details of the format look at autofs(5).
# Include central master map if it can be found using
# nsswitch sources.
# Note that if there are entries for /net or /misc (as
# above) in the included master map any keys that are the
# same will not be seen as the first read key seen takes
Server /etc/exports file:
[root@redwood ~]# rpcinfo -p
program vers proto port
100000 2 tcp 111 portmapper
100000 2 udp 111 portmapper
100007 2 udp 648 ypbind
100007 1 udp 648 ypbind
100007 2 tcp 651 ypbind
100007 1 tcp 651 ypbind
100024 1 udp 622 status
100024 1 tcp 628 status
100021 1 udp 32771 nlockmgr
100021 3 udp 32771 nlockmgr
100021 4 udp 32771 nlockmgr
100021 1 tcp 58162 nlockmgr
100021 3 tcp 58162 nlockmgr
100021 4 tcp 58162 nlockmgr
-bash-3.1$ dig spruce.highley-recommended.com
; <<>> DiG 9.3.3rc3 <<>> spruce.highley-recommended.com
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 15621
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 1
;; QUESTION SECTION:
;spruce.highley-recommended.com. IN A
;; ANSWER SECTION:
spruce.highley-recommended.com. 86400 IN A 10.2.2.2
;; AUTHORITY SECTION:
highley-recommended.com. 86400 IN NS hemlock.highley-recommended.com.
highley-recommended.com. 86400 IN NS spruce.highley-recommended.com.
;; ADDITIONAL SECTION:
hemlock.highley-recommended.com. 86400 IN A 10.2.2.3
;; Query time: 4 msec
;; SERVER: 10.2.2.3#53(10.2.2.3)
;; WHEN: Thu Jan 18 19:24:58 2007
;; MSG SIZE rcvd: 116
(In reply to comment #6)
> -bash-3.1$ ypcat -k auto.master
> /net -hosts
> /misc /etc/auto.misc
> /home /etc/auto.home
What's in "/etc/auto.home" on the client machine?
> -bash-3.1$ ypcat -k auto.home
> * douglas.highley-recommended.com:/export/home/&
If you don't have an "/etc/auto.home" on the client then
create one with the above line in it and see what happens.
Creating a local /etc/auto.home file with the same information fixes the login
automount issue. So where does that leave us. If I can use the ypcat commands to
dump the map files on the client and the passwd map file must be present or the
user would not exist for the login is the auto.home file not present?
Because your master map points explicitly to /etc/auto.home, you need to provide
that map. You can include the NIS auto.home by creating /etc/auto.home with the
This sounds like it would be the most sane configuration.
The last sentence in your update is a bit difficult to follow (pesky English).
I believe you want to know if the problem is that there is no /etc/auto.home
file present. This is the case. Autofs was complaining because the map pointed
at /etc/auto.home, and that file dose not exist. You may want to see how the
other systems that work are configured in this regard.
If you agree with this diagnosis, then please close the bug at your convenience.
(In reply to comment #9)
> Because your master map points explicitly to /etc/auto.home, you need to provide
> that map. You can include the NIS auto.home by creating /etc/auto.home with the
> single entry:
> This sounds like it would be the most sane configuration.
And don't forget that for autofs to look for a map in NIS
/etc/nsswitch.conf must contain "nis" as a source (sorry but
I have to say this for completeness).
automount: files nis
Aditionally, if you feel that it won't cause a problem for the
other systems you could change your master map /home entry to
and ensure nsswitch is setup as above.
Yes, I believe the best solution is to change the auto.master file to be:
I think it was my mistake but very confusing that two of the clients would work
without the existence of a /etc/auto.home file but the third system would not.
So is it a bug, probably but also not worth wasting bandwitdth on chasing
although I probably have 15-20 hours lost in debugging the issue. Thanks
The bug is with your other systems. What operating system are they running
(older RHEL, maybe)? I'm changing the status here to NOTABUG, because for the
system you described, it was a configuration error.
All four systems are Fedora core 6 with the latest updates; not kernel 2.6.19