Bug 159726
Summary: | NIS maps will not load correctly on a user login | ||
---|---|---|---|
Product: | Red Hat Enterprise Linux 3 | Reporter: | David Mullins <david.mullins> |
Component: | autofs | Assignee: | Jeff Moyer <jmoyer> |
Status: | CLOSED NOTABUG | QA Contact: | Brock Organ <borgan> |
Severity: | medium | Docs Contact: | |
Priority: | medium | ||
Version: | 3.0 | ||
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | i386 | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2006-04-17 19:45:56 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
David Mullins
2005-06-07 14:48:59 UTC
Please see the section entitled "Filing bug reports" on the following web page: http://people.redhat.com and provide the information requested. this website is a dead-end link, how am I to provide the information needed? All this shows is the url, a redhat logo, and a powered by redhat graphic that links back to redhat.com. <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html> <head> <title>people.redhat.com</title> <link rel="icon" href="/icons/shadowman-16.png" type="image/png"/> </head> <body bgcolor="#FFFFFF" text="#000000" link="#000066" vlink="#333399" alink="#FF0000"> <br/> <div align="center"> <img src="/icons/people.redhat.com.png" width="374" height="194" alt="people.redhat.com" /> </div> <br> <p align="center"> <a href="http://www.redhat.com/" align="center"><img src="/icons/poweredby.png" align="center" alt="[ Powered by Red Hat Linux ]"></a> </p> </body> </html> Sorry about that! That should have read: http://people.redhat.com/jmoyer/ # autofs rpm version, obtained via 'rpm -q autofs' it is autofs-4.1.3-130 # kernel version, obtained via 'uname -r' 2.4.21-20.ELsmp # contents of your autofs maps. This includes auto.master and at least the map which is problematic for you. the auto.home file that works with fine with RH 7.3, 9, and AS3(no updates) clients but not with AS3update3 or AS3update5 clients. The NIS map is formated as follows: user -rw machine:/export/home/user The files system is shared and exportfs reports /export/home <world> (These machines are not on an outside network.) (ypcat auto.home does return the correct information) # debug output. I will be unable to attach logs as this is not a connected system. here is the relevant data: timestamp machine syslogd 1.4.1: restart. timestamp machine autofs: automount shutdown succeeded timestamp machine automount[PID]: starting automounter version 4.1.3-130, path = /home, maptype = yp , mapname = auto.home timestamp machine autofs: automount startup suceeded timestamp machine automount[PID]: mount(bind): bind_works = 1 timestamp machine automount[PID]: mount_autofs: already mounted timestamp machine automount[PID]: /home: mount failed! timestamp machine su(pam_unix)[PID]: session opened for user user by root (uid=0) It is at this point that on a nis login the login succeeds but the home directory of the user is not loaded. Could you attach your /etc/auto.master file as an attachment? Please stop the automounter and send the output from the mount command with no options. And, as Chris said above, please send the contents of auto.master. The error message states that the directory '/home' is already mounted. Are you trying to automount on top of a mount point? -Jeff /etc/auto.mater has the one that comes with the distribution. It has no uncommented lines. there is a reference to /dev/sda5 mounted to home. I assume this must be the problem. This is not a problem for the older 3.x version of autofs. with this entry removed it will now load this map. Is this the new default behavior for this version of autofs? Yes. I instituted this change due to several bug reports from users. If you did a service autofs restart, and the mount point was busy so didn't unmount, then autofs would mount over an existing automounted file system. This made for interesting inconsistencies that could case side effects such as not being able to unmount the directory in question. If this is a problem for you, then it is feasible to change the is_mounted check to check for a mount point that is of type autofs. If it isn't an autofs mount point, then we could succeed. However, is this really the behaviour you want? Why would you mount /home from a block device, and then just overwrite it? I can think of maybe one corner case where you'd want this behaviour. This may not be the behavior I wanted, but it was what I expected. We use a custom install for everything one size fits all. This then caused some issues when we upgraded those machines and the few that were on NIS did not behave as expected. I started to look into it for a solution and a likely cause. I may have to attempt to institute an is_mounted check similar to what you have mentioned. David, I'm going to close this as NOTABUG. The situation you describe is really a corner case, and an error is logged via syslog when this happens. Thanks. |