nisinit Fails
Make sure that:
You can ping the NIS+ server to check that it is up and running as a machine.
The NIS+ server that you specified with the -H option is a valid server and that it is running the NIS+ software.
rpc.nisd is running on the server.
The nobody class has read permission for this domain.
The netmask is properly set up on this machine.
Checkpoint Keeps Failing
If checkpoint operations with a nisping -C command consistently fail, make sure you have sufficient swap and disk space. Check for error messages in syslog. Check for core files filling up space.
Cannot Add User to a Group
A user must first be an NIS+ principal client with a LOCAL credential in the domain's cred table before the user can be added as a member of a group in that domain. A DES credential alone is not sufficient.
Logs Grow too Large
Failure to regularly checkpoint your system with nisping -C causes your log files to grow too large. Logs are not cleared on a master until all replicas for that master are updated. If a replica is down or otherwise out of service or unreachable, the master's logs for that replica cannot be cleared. Thus, if a replica is going to be down or out of service for a period of time, you should remove it as a replica from the master as described in "Removing a Directory". Keep in mind that you must first remove the directory's org_dir and groups_dir subdirectories before you remove the directory itself.
Lack of Disk Space
Lack of sufficient disk space will cause a variety of different error messages. (See "Insufficient Disk Space" for additional information.)
Cannot Truncate Transaction Log File
First, check to make sure that the file in question exists and is readable and that you have permission to write to it.
You can use ls /var/nis/trans.log to display the transaction log.
You can use nisls -l and niscat to check for existence, permissions, and readability.
You can use syslog to check for relevant messages.
The most likely cause of inability to truncate an existing log file for which you have the proper permissions is lack of disk space. (The checkpoint process first creates a duplicate temporary file of the log before truncating the log and then removing the temporary file. If there is not enough disk space for the temporary file, the checkpoint process cannot proceed.) Check your available disk space and free up additional space if necessary.
Domain Name Confusion
Domain names play a key role in many NIS+ commands and operations. To avoid confusion, you must remember that, except for root servers, all NIS+ masters and replicas are clients of the domain above the domain that they serve. If you make the mistake of treating a server or replica as if it were a client of the domain that it serves, you may get Generic system error or Possible loop detected in namespace directoryname:domainname error messages.
For example, the machine altair might be a client of the subdoc.doc.com. domain. If the master server of the subdoc.doc.com. subdomain is the machine sirius, then sirius is a client of the doc.com. domain. When using, specifying, or changing domains, remember these rules to avoid confusion:
Client machines belong to a given domain or subdomain.
Servers and replicas that serve a given subdomain are clients of the domain above the domain they are serving.
The only exception to Rule 2 is that the root master server and root replica servers are clients of the same domain that they serve. In other words, the root master and root replicas are all clients of the root domain.
Thus, in the example above, the fully qualified name of the altair machine is alladin.subdoc.doc.com. The fully qualified name of the sirius machine is sirius.doc.com. The name sirius.subdoc.doc.com. is wrong and will cause an error because sirius is a client of doc.com., not subdoc.doc.com.
Cannot Delete org_dir or groups_dir
Always delete org_dir and groups_dir before deleting their parent directory. If you use nisrmdir to delete the domain before deleting the domain's groups_dir and org_dir, you will not be able to delete either of those two subdirectories.
Removal or Disassociation of NIS+ Directory from Replica Fails
When removing or disassociating a directory from a replica server you must first remove the directory's org_dir and groups_dir subdirectories before removing the directory itself. After each subdirectory is removed, you must run nisping on the parent directory of the directory you intend to remove. (See "Removing a Directory".)
If you fail to perform the nisping operation, the directory will not be completely removed or disassociated.
If this occurs, you need to perform the following steps to correct the problem:
Make sure that org_dir.domain does not appear in /var/nis/rep/serving_list on the replica.
Perform a nisping on domain.
From the master server, run nisrmdir -f replica_directory.
If the replica server you are trying to dissociate is down or out of communication, the nisrmdir -s command will return a Cannot remove replica name: attempt to remove a non-empty table error message.
In such cases, you can run nisrmdir -f -s replicaname on the master to force the dissociation. Note, however, that if you use nisrmdir -f -s to dissociate an out-of-communication replica, you must run nisrmdir -f -s again as soon as the replica is back on line in order to clean up the replica's /var/nis file system. If you fail to rerun nisrmdir -f -s replicaname when the replica is back in service, the old out-of-date information left on the replica could cause problems.
NIS+ Database Problems
This section covers problems related to the namespace database and tables. Common symptoms include error messages with operative clauses such as:
Abort_transaction: Internal database error
as well as when rpc.nisd fails.
See also "NIS+ Ownership and Permission Problems".