So you have a Solaris 10 operating environment and you’re getting “permission denied” errors when trying to change a user’s password while logged in as root.

So you check /var/adm/messages for some clues and you see a message like this:

sunbox# tail /var/adm/messages

Aug  1 13:31:08 sunbox yppasswdd[1221]: [ID 467562 auth.error] yppasswdd: user test_user: does not exist

You know that the user exists, and can still see the user in your NIS passwd files using a command like this:

ypcat passwd | grep test_user

So how do you fix it?

You can restart your NIS processes using this command:

svcadm restart nis/server

Sometimes that will resync the NIS files and processes and get things back in working order. Sometimes you still get the same error.

What finally fixed my “passwd change permission denied” error was actually quite simple once I figured out what the problem was.

At times your NIS map files can become out of sync and need to be rebuilt. This “Passwd Permission Denied” problem can be caused by a recommended Solaris security patch that may have replaced your custom NIS Makefile with a standard issue Solaris one that has PWDIR = /etc and not PWDIR = /var/yp. Using /var/yp instead of /etc is done to separate local system accounts such as root from the standard NIS user accounts of a workgroup.

If you find your NIS Makefile changed from PWDIR = /var/yp to PWDIR = /etc then your users may not be able to login at all and they’ve probably already come running for their system admin. You may need to recover your original NIS Makefile from the backup you ran before patching. You did make a backup right? Or the patch script may have taken you original Makefile and named it Makefile.old or something. You can run a “diff” on those two files to see what changed. If the Solaris patch made changes unhealthy to your career, replace the new Makefile with the Makefile.old file.

A restart of the NIS/YP services is necessary to bring all of the map files back into sync. If a restart of the services doesn’t work, check your NIS directory (usually /var/yp or /etc) for a lockfile.

sunbox# ls -al

-rw-------     1  root     root          0  Aug  1 09:42 .pwd.lock

I removed the lockfile and restarted the NIS/YP processes:

sunbox# rm .pwd.lock

sunbox# /usr/lib/netsvc/yp/ypstop

sunbox# /usr/lib/netsvc/yp/ypstart

You should see a message like this when restarting the NIS processes:

starting NIS (YP server) services:  ypserv ypbind ypxfrd rpc.yppasswdd rpc.ypupdated done.

After restarting, you should be able to see the processes running with “ps” command:

sunbox# ps -ef | grep yp

Now you should be able to reset your users NIS passwords without the “permission denied” error by running the “passwd” command:

sunbox# passwd -r nis <username>

Notes on NIS and YP:

NIS, or Network Information Service, was originally called Yellow Pages or YP, which is why the NIS commands begin with “yp”. Since the term “Yellow Pages” is a registered trademark of British Telecom PLC for it’s non-digital, old school paper commercial telephone directory, Sun changed the name of its system to NIS.

NIS+ commands no longer use “yp” commands.

Since NIS was developed before the public internet, robust security was never a feature. NIS will work fine on a closed research network but is not recommended for any network that touches the internet. There are more modern options to choose from such as NIS+ and LDAP. But if you’re stuck administering a legacy research network that has no funding to upgrade, then you still have to know how to deal with the quirks of NIS.

Existing NIS maps can be (and should be) migrated to other systems such as NIS+ or LDAP. Some shops even use Windows Active Directory for authentication of Linux and Solaris machines.