Hide Forgot
From Bugzilla Helper: User-Agent: Mozilla/4.77 [en] (X11; U; Linux 2.4.3-12 i686) Description of problem: Using a full install of 7.2, with shadow passwords and MD5 enabled, and running NIS from a Solaris server, it is impossible to change the root password. Even though files comes before nis in the /etc/nsswitch.conf file, the passwd command tries to change the password on the NIS server, which is not permitted when you are trying to change the root password. Using the linuxconf change root password GUI also resulted in the same error message. Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: 1.turn on NIS, shadow passwords, MD5 2.as root issue the passwd command 3.observe the error message from the NIS server telling you that the password has not been changed Actual Results: RPC: Can't encode arguments The password has not been changed on tachyon.uchicago.edu. passwd: Failed preliminary check by password service Expected Results: The password for root should have been changed on the local machine only. Additional info:
*** Bug 55615 has been marked as a duplicate of this bug. ***
*** Bug 43915 has been marked as a duplicate of this bug. ***
Do you have a root account in NIS in addition to the one defined in the local files?
Yes, the NIS database does have an entry listed for root. However, the nsswitch.conf is saying to search the local files before looking at the NIS database.
I really would consider this a configuration error -- enumeration of the passwd database (for example, by running "getent passwd") will show two accounts for root, with two passwords, but only one of them will ever work. This is because the function for reading a single passwd record only returns a single result. As a workaround, removing "nis" from the line in /etc/pam.d/system-auth which includes use of pam_unix for changing passwords will prevent pam_unix from attempting to change passwords on the NIS server. This happens because the function which looks up a user's information doesn't tell pam_unix where the information came from, so pam_unix checks both NIS and local files to figure out which entry to change, and it appears to be hitting on the wrong data source.
No, here we don't have an entry for root in NIS. Moreover, here it is not at all related to the root account and both client/server run rh 7.2. Probably #43915 is not a duplicate of this bug after all!?
It should be duplicate of bug 43915 however regarding comment #6 - if it still happens to you on a current RHEL/Fedora releases please write it here. *** This bug has been marked as a duplicate of 43915 ***