The Solaris group is a forum where peers share technical expertise, solve problems, and discuss issues related to the Solaris operating system, including OS-related malfunctions, security issues, and network performance.

password-r nis &lt;username&gt; on nis client-Permission Denied

Hi,
This may have been discussed earlier , but I have not found a solution
searching ..
Using Solaris 10, NIS -Server and Solaris 10 - NIS client
Authentication works fine for each user( configured in nis server)
When a user logs in to NIS Client, tried below,
yppasswd upennis
Enter existing login password:
New Password:
Re-enter new Password:
Permission denied

Hey Aero,
I thought yppasswd was deprecated, but who knows these days? Old is new,
new is old, yadda, yadda...
It has been a while since I worked with NIS, but have you checked the yp
binding on all your clients? Is this client bound directly to the NIS
Master, or is it bound to a slave server, which is bound to the NIS master?
Is this client in local /etc/hosts file on the NIS master server? Your
error message makes it sound like it is not. Have you tried to re-run
ypinit -c on that host to verify it is connected to a master or slave
server? Have you recently updated any of your files in /etc on the NIS
master, but not pushed the changes to the slave servers? What about
/etc/nsswitch.conf? Does the passwd entry say "files nis" or "nis files"?
And my last question for this post: Are you trying to change the passwd on
the master server, or locally? Your output indicates you are trying to
change the passwd on the NIS master. If you are trying to change the passwd
on the NIS master, use "passwd <username>".
HTH.

Help the community by fixing grammatical or spelling errors, summarizing or clarifying the solution, and adding supporting information or resources. Always respect the original author.

Popular White Paper On This Topic

Hey Aero,
I thought yppasswd was deprecated, but who knows these days? Old is new,
new is old, yadda, yadda...
It has been a while since I worked with NIS, but have you checked the yp
binding on all your clients? Is this client bound directly to the NIS
Master, or is it bound to a slave server, which is bound to the NIS master?
Is this client in local /etc/hosts file on the NIS master server? Your
error message makes it sound like it is not. Have you tried to re-run
ypinit -c on that host to verify it is connected to a master or slave
server? Have you recently updated any of your files in /etc on the NIS
master, but not pushed the changes to the slave servers? What about
/etc/nsswitch.conf? Does the passwd entry say "files nis" or "nis files"?
And my last question for this post: Are you trying to change the passwd on
the master server, or locally? Your output indicates you are trying to
change the passwd on the NIS master. If you are trying to change the passwd
on the NIS master, use "passwd <username>".
HTH.

Yppasswd is deprecated in sol 10 it should be passwd -r nis. What is the
output of ypbind on the client, is it correct. can you ypcat the passwd
file on the client, and when you do, do you get the entry for the
particular user you are trying to change the passwd for. Make sure the
clients know about the server ie entry in /etc/hosts, make sure the
server knows about the clients by which ever means it does its hostname
resolution (I always make sure my servers local hosts map echoes the nis
hosts map). Have you tried changing the passwd for any other user from
the same client, do you have another client that you can try for the
same user.
Have you made any changes to the nis client or server in terms of adding
it to the nis etc if you have and its ok to do so I'd reboot it (yeah I
know its a very MS thing to do but just simplifies life when ok to do
so), or your other option is to restart the services (ypbind or
nis_client as is in sol 10 svcs)that use the configs you've changed.
I have seen this sort of problem before but only when a client has just
been put in the domain and hasn't had the relevant services restarted,
hence the reboot, or the server has just been setup and hasn't had
everything restarted so a reboot just clears everything up. I had the
same sort of problem when I changed my server to C2Secure nis, until I
rebooted the server the clients could see all the maps and get the
relevant