Common Problems with NIS+

Make sure you typed the name of the object correctly and specified the correct path. The path to a system table must include “org_dir.” The path to an NIS+ group must include “groups_dir,” unless it is an argument to the nisgrpadm command, which cannot find a group if you include “groups_dir” in its path.

Make sure the value of the NIS_PATH variable includes the domain where the object resides. If the NIS_PATH variable is not set, the default search path is the default domain and all domains up to the root domain. See “Change the Search Order of Domains”.

If you are logged into a non-root server, and you are searching for an object in the domain the server serves, specify the full path name of the object, including the domain. A non-root server is a client of its parent domain, and any searches initiated from the server will search the server’s parent domain by default.

Make sure any fully qualified names end with a period. If a name does not end with a period, NIS+ appends a domain name to it.

Make sure the object exists. Issue the nisls -l directory command, where directory is the directory where the object should exist.

If the object was created recently, the replica servers might not have been updated yet. You can issue the nisping(1M) command to synchronize the replica servers, or you can just wait a few minutes for the replicas to synchronize themselves automatically.

If the object is configured in an AutoFS map, use the niscat(1) command to make sure your AutoFS maps contain the proper information. If the source files or NIS maps used to build the NIS+ tables contained periods in their names, NIS+ cannot build the tables correctly. Before you run nissetup(1M) or nisserver(1M) to set up an NIS+ master server, replace periods in AutoFS map names with underbars. For example, if your master map is called auto.master, rename it to auto_master.

Issue the nisls -l command in the directory where the object should exist, and look closely to make sure the object name does not begin with a blank. If you type an extra space before the object name when you create an object, some NIS+ commands take the space as part of the object name. Rename the object, or remove it and recreate it without the extra space.

A table or log file may have been corrupted. Restore the file from your most recent backup.

If you have changed the name of a domain, many NIS+ operations will fail, because the old domain name is embedded in objects throughout the domain. Do not change the name of an existing domain. If you have already done so, change the name back to the original. To rename a domain, create a new domain, initialize clients in the new domain, and then remove the old domain.

Issue the following command to determine whether you are authenticated:

niscat passwd.org_dir

If you are authenticated, you should be able to see the encrypted password field for your user ID. If you are not authenticated, the password field for your user ID will display *NP*.

If you are not authenticated, try to keylogin using your login password. If that does not work, try the password “nisplus”. If that does not work, try your most recent login password.

If the error you see is “Password does not decrypt sectet key,” you can probably fix it by issuing the keylogin command. This error is normal if you are running in a secure environment where a user’s login password and secure RPC password are different. Users whose login and secure RPC password should be the same can fix this error by performing a keylogin and then issuing the following command:

/usr/lib/nis/nisclient -u

If you are a root user on an NIS+ replica server, and you cannot become authenticated, recreate the credentials for the replica, then remove and add the replica. See “Create New Credentials for an Existing NIS+ Principal”, “Remove a Replica Server from an NIS+ Domain”, and “Set Up NIS+ Replica Servers”.

If you are a root user on the root master server, and you cannot become authenticated, recreate the credentials for the root master server. See “Create New Credentials for the Root Master Server”.

Use the niscat(1) or nismatch(1) command to make sure the cred table contains credentials for you. If necessary, log in as an authenticated user and issue the nisaddcred(1M) command to create credentials for your NIS+ principal.

Issue the niscat -o command to check the ownership and permissions on the object you are trying to access. If necessary, use the nischmod(1) command to modify the permissions on the object.

If you must be a member of an NIS+ group to access the object, issue the nisgrpadm -l command to make sure your NIS+ principal name is included in the group. If necessary, use the nisgrpadm(1) command to add your principal name to the group.

Issue the ps -ef command to make sure the keyserv(1M) daemon is running. If it is not, start it. Make sure automountd, rpc.nisd, and sendmail are running. If they are not, start them.

If you changed the root password with the nispasswd command, log in as a user with modify permission for the passwd and cred tables, and change the root password back. To change the root password, issue the passwd command followed by the chkey -p command.

	CAUTION: You can change the root password on the root master server, but do not change the public or private key on the root master server. The root master server’s keys are embedded in every directory object on every client, replica server, and subdomain server.

Make sure the NIS+ hosts table does not contain a host with the same name as the user. If a host has the same name as a user, one credential will overwrite the other, and either the user or the root user will no longer be able to perform a keylogin. (The keylogin is performed automatically when a user logs in, if the user’s login password is the same as the user’s secure RPC password.)

Use nismatch(1) to find the credentials for the user or host in the cred table. If both a Local and a DES credential exist, the credentials are for a non-root user. If only a DES credential exists, the credential is for a root user. If necessary, change the host name. (It is easier to change a host name than to change a user name.) You can set up an alias to map the host’s old name to the new name.

	NOTE: When you are running nisaddcred or nisclient, if you see a Changing Key message instead of an Adding Key message, you have a duplicate user or host name in your domain.

If you have recently changed the default domain of a client host, remove the /etc/.rootkey file on the host and rerun the nisclient(1M) script to initialize the host.

If a user’s login password is different from the user’s secure RPC password, the user must perform a keylogin after login in order to become authenticated.

If a user logs into a remote host that does not require a password, for example, because it has an entry for the user in a $HOME/.rhosts or /etc/hosts.equiv file, the user must perform a keylogin after login in order to become authenticated.

Make sure the publickey entry in the /etc/nsswitch.conf file is set to nisplus.

A user’s or host’s credentials may have become corrupted. If the user experiencing the problem is a non-root user, tell the user to issue the keylogout command followed by the keylogin command. If the user experiencing the problem is a root user, tell the root user to remove the /etc/.rootkey file and then issue the keylogout -f command followed by the keylogin -r command.

An out-of-date /etc/.rootkey file might exist. Use the ls -l command to compare the date on the /etc/.rootkey file with the date on the cred.org_dir table. If the /etc/.rootkey file is much older than the cred table, it could be out of date. Run keylogin -r as root on the problem host, and then reinitialize the host as an NIS+ client.

If your server is running at security level 0, and you try to run nispasswd to change your password, NIS+ will display an error message saying that you do not have secure RPC credentials for the domain.

If you have changed the name of a domain, many NIS+ operations will fail, because the old domain name is embedded in objects throughout the domain. Do not change the name of an existing domain. If you have already done so, change the name back to the original. To rename a domain, create a new domain, initialize clients in the new domain, and then remove the old domain.

As a short-term solution to free up memory, kill all unnecessary windows and processes. If necessary, exit your windowing system and work from the terminal command line.

Use the ps -el command to check the size of running processes. Sometimes programs develop memory leaks and grow very large. If necessary, compare the size of processes on your host with processes on a host that is not having memory problems to determine whether the processes on your host are growing too large.

As a long-term solution, install more memory or swap space, or move your NIS+ server to a system that has more memory or swap space.

If you have a shortage of disk space, clean out the /tmp directory and remove any unnecessary files. Remove core files from the root directory and home directories.

If you do not checkpoint your transaction log regularly, it becomes very large. However, in order to checkpoint your transaction log, you need sufficient disk space to allow NIS+ to make a complete copy of the log before removing it. You might have to add disk space to your server before checkpointing the log.

To checkpoint the log, issue the nisping -Ca command. If your transaction log is large, or if you have a large number of replica servers, the nisping command can take a long time. It is recommended that you create a cron job to run nisping -Ca every night while the network is not busy.

Kill any unnecessary processes on your server host. This message occurs when your host has run out of available processes.

If necessary, follow this procedure to increase the maximum number of inodes on your NIS+ server:

Have the user issue the keylogin command using the user’s secure RPC password. In most cases, this password should be the same as the user’s login password. If the keylogin does not work, have the user try it with the password “nisplus.” If that doesn’t work, have the user try to keylogin with his or her most recent password.

If the user changed passwords with the passwd command, the user will not be able to log into an NIS+ host. The passwd command affects only the /etc/passwd file on the local host. Users must run nispasswd to change their passwords in the NIS+ passwd table. If your NIS+ server is running in NIS compatibility mode, users on NIS clients must issue the yppasswd command to change their passwords in the NIS+ passwd table.

After a user has changed passwords, there may be a delay before the new password is propagated through the domain. This delay can be as long as many minutes, depending on the size of your domain. The problem will probably resolve itself if you wait, or you can issue the nisping org_dir command to force the servers to resynchronize.

If the user is trying to log into a host in a remote domain, use nismatch(1) to make sure the remote domain has a Local credential for the user. Use nisaddcred(1M) to add a Local credential for the user if none exists.

Use the niscat(1) command to make sure your AutoFS maps contain the proper information. If the source files or NIS maps used to build the NIS+ tables contained periods in their names, NIS+ cannot build the tables correctly. Before you run nissetup(1M) or nisserver(1M) to set up an NIS+ master server, replace periods in AutoFS map names with underbars. For example, if your master map is called auto.master, rename it to auto_master.

If the /etc/nsswitch.conf file has been modified recently on the user’s host, reboot the host to make sure all processes are using the new configuration.

Make sure the NIS+ hosts table does not contain a host with the same name as the user. If a host has the same name as a user, one credential will overwrite the other, and either the user or the root user will no longer be able to perform a keylogin. (The keylogin is performed automatically when a user logs in, if the user’s login password is the same as the user’s secure RPC password.)

Use nismatch(1) to find the credentials for the user or host in the cred table. If both a Local and a DES credential exist, the credentials are for a non-root user. If only a DES credential exists, the credential is for a root user. If necessary, change the host name. (It is easier to change a host name than to change a user name.) You can set up an alias to map the host’s old name to the new name.

	NOTE: When you are running nisaddcred or nisclient, if you see a Changing Key message instead of a Adding Key message, you have a duplicate user or host name in your domain.

Issue the following command to check the update status of your replica servers:

nisping -u

If you do not issue the nisping -Ca command regularly, your transaction log may grow too large, and you may not have enough disk space to checkpoint it.

Make sure every master server in your namespace has a cron job that runs nisping -Ca at least once a day, during a time when the network is not busy. The following example crontab file runs nisping -Ca once a day, at 3:00 AM. It directs standard output and standard error from the nisping command to the file /tmp/nisping.log.

0 3 * * * /usr/lib/nis/nisping -Ca > /tmp/nisping.log 2&>1

The nisping -Ca command causes all servers of the domain to update their tables with the changes in the transaction log and to clear the transaction log.

The most common cause of a checkpoint failure is lack of swap or disk space. The checkpoint process creates a temporary copy of the transaction log before it truncates the log and removes the temporary copy. Check your available swap and disk space, and free up all that you can. Remove core files. If necessary, configure more swap space.

One or more replica servers may be down. Logs are not cleared on a master server until all replicas for the master’s domain have been updated. If a replica server is going to be down or out of service for a period of time, issue the nisrmdir -s command to remove it as a replica.

Make sure the /var/nis/hostname.log file exists. Make sure it is readable and that you are allowed to write to it.

Check for error messages in syslog. Appendix A “NIS+ Error Messages” lists the NIS+ error messages, their causes, and the actions you can take to resolve them.

The master server might be busy, or another replica might be performing an update. The update is usually rescheduled automatically and retried later.

The server might be out of child processes to allocate. See “An “Unable to Fork” Message”.

A read-only process might have been requested to dump.

You may have attempted to create a table with no searchable columns. See “Create an NIS+ Table”.

A database operation may have returned the error code DB_BADOBJECT. Type man 3N nis_db for a list of error codes and their meanings.

You may have tried to add or modify an object with a length of zero.

You may have tried to perform an NIS+ directory operation on an object that was not a directory.

You may have tried to link an NIS+ directory to a LINK object.

You may have specified an NIS+ object that was not a group in the nisgrpadm command or in another NIS+ group operation.

You may have tried to perform an NIS+ table operation on an object that was not a table.

Issue the following command to make sure your default domain name does not end with a period:

domainname

In the /etc/rc.config.d/namesvrs file, make sure the value of the NIS_DOMAIN variable does not end with a period.

Issue the following command to determine whether you have multiple independent rpc.nisd processes running:

ps -ef | grep nisd

In normal operation, rpc.nisd may spawn child rpc.nisd processes, and this causes no problem. However, if two parent rpc.nisd processes are running on the same host at the same time, they will overwrite each other’s data and corrupt logs and databases. (Two parent rpc.nisd processes can be running only if someone started one by hand.)

If you have more than one parent rpc.nisd process running, issue the kill -9 processID command to kill all but one of them, and then issue the ps -ef command again to make sure only one parent process remains. If you are running rpc.nisd in NIS compatibility mode (with the -Y or -B option), kill all independent rpc.nisd_resolv processes as well.

If an NIS+ table is corrupt, restore it from your most recent backup that contains an uncorrupted version. You can then use your transaction logs to update the table with any changes that occurred since the backup was made. However, if the transaction log is also corrupt, you must recreate your NIS+ environment. You can do this in one of two ways: