Thanks Brandon and Takashi

Unfortunately I cannot test this until I get home (on vacation which I am
breaking doing this and sadly the next email I send to the group)Š   I can
try this on my return to the office (but at that point the upgrade wave
that we are currently doing will reach the NIS server and it too will be
running SL).  

Thanks,
Bill


On 8/4/14, 02:46 EDT, "Takashi ichihara" <[log in to unmask]>
wrote:

>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-i
>s-stuck-on-nobody
>
>(14/08/04 8:01), Brandon Vincent wrote:
>> On Sun, Aug 3, 2014 at 2:26 PM, Capehart, William J
>> <[log in to unmask]> 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
>>