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
Version-Release number of selected component (if applicable):
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.
*** 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
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 ***