Bill,
You can check your NIS password map by "ypcat passwd" command
on your NIS client. Second field should be hashed password of
13 characters.
I am not sure whether the issue below is related to your case or not.
In the NIS/NFS environment in SL, we noticed NSF mount problems accrued
starting from SL6.3 and still exist in SL6.5. The nfs mount
in SL6.3, 6.4, 6.5 (also CentOS 6.3-6.5) would not map the user ids
correctly. Specific uids become 99(nobody) on the NFS(NFS4) client
of SL 6.3-6.5.
The issue was idmapd had cached the incorrect ids from the faulty
configuration, and no fixing of the configuration would sort it.
The command to fix this is nfsidmap -c (clear cache).
Regards,
Takashi
http://serverfault.com/questions/364613/centos-6-ldap-nfs-file-ownership-is-stuck-on-nobody
(14/08/04 8:01), Brandon Vincent wrote:
On Sun, Aug 3, 2014 at 2:26 PM, Capehart, William J
<william.capeh...@sdsmt.edu> wrote:
Ypwich -m matches 1:1 as well. As I said I am hoping to get rid of this
problem when all machines in our fleet jump to SL 6.5 in the next couple
weeks.
Bill
Bill,
Your problem might be due to the fact that Mandriva 2009 can use tcb
as an alternative to /etc/shadow.
http://www.openwall.com/tcb/
Hashes generated from tcb are not compatible with the traditional
pam_unix.so found in almost every other GNU/Linux distribution.
Can you verify on the NIS server that your hashes are stored in the
traditional /etc/shadow format?
Brandon Vincent
