Description of problem: Automounted home directory fails to mount at login. Version-Release number of selected component (if applicable): selinux-policy-targeted-2.4.6-23.fc6 How reproducible: Every time. Steps to Reproduce: 1.Try logging into the system. 2. 3. Actual results: ls -dZ /home drwxr-xr-x root root system_u:object_r:home_root_t /home Expected results: The three other systems that work show: drwxr-xr-x root root system_u:object_r:autofs_t /home Additional info: 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 /var/log/audit.log file: 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[14151]: mount_autofs_indirect: failed to read map for /home Jan 17 20:18:43 redwood automount[14151]: handle_mounts: mount of /home failed! Jan 17 20:18:43 redwood automount[14151]: master_do_mount: failed to st artup mount
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 /etc/nsswitch.conf. 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 /net -hosts /misc /etc/auto.misc /home /etc/auto.home +auto.master -bash-3.1$ ypcat -k auto.home * douglas.highley-recommended.com:/export/home/& -bash-3.1$ ypmatch -k spruce hosts spruce 10.2.2.2 spruce.highley-recommended.com spruce internal ftp-i /etc/nsswitch.conf: hosts: files dns nis automount: files nis /etc/hosts -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 /etc/auto.master: -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). # /misc /etc/auto.misc /net -hosts # # 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 # precedence. # +auto.master Server /etc/exports file: /export/home *.highley-recommended.com(rw) [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? > +auto.master > > -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. Ian Ian
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 single entry: +auto.home 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. Thanks!
(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: > > +auto.home > > 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). For example: 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 /home auto.home and ensure nsswitch is setup as above. Ian
Yes, I believe the best solution is to change the auto.master file to be: /home auto.master 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 until tonight.