This section describes problems related to user ownership and permissions. Common symptoms include:
Error messages with operative clauses such as:
Unable to stat NIS+ directory name
User or root unable to perform any namespace task.
The most common permission problem is the simplest: you have not been granted permission to perform some task that you try to do. Use niscat -o on the object in question to determine what permissions you have. If you need additional permission, you, the owner of the object, or the system administrator can either change the permission requirements of the object (as described in Chapter 15, Administering NIS+ Access Rights) or add you to a group that does have the required permissions (as described in Chapter 17, Administering NIS+ Groups).
Without proper credentials for you and your machine, many operations will fail. Use nismatch on your home domain's cred table to make sure you have the right credentials. See Corrupted NIS+ Credentials for more on credentials-related problems.
A server running at security level 0 does not create or maintain credentials for NIS+ principals.
Security level 0 is only to be used by administrators for initial namespace setup and testing purposes. Level 0 should not be used in any environment where ordinary users are active.
A user cannot have the same login ID as a machine name. When a machine is given the same name as a user (or a user has the same name as a machine), the first principal can no longer perform operations requiring secure permissions because the second principal's key has overwritten the first principal's key in the cred table. In addition, the second principal now has whatever permissions were granted to the first principal.
For example, suppose a user with the login name of saladin is granted namespace read-only permissions. Then a machine named saladin is added to the domain. The user saladin will no longer be able to perform any namespace operations requiring any sort of permission, and the root user of the machine saladin will only have read-only permission in the namespace.
Either the user or root for that machine cannot successfully run keylogin.
If the first principal did not have read access, the second principal might not be able to view otherwise visible objects.
nismatch username passwd.org_dir
Then run nismatch on the domain's cred table to see what type of credentials are provided for the duplicate host or user name. If there are both LOCAL and DES credentials, the cred table entry is for the user; if there is only a DES credential, the entry is for the machine.
the machine name. (It is better to change the machine name than to change
the user name.) Then delete the machine's entry from the
cred table and use nisclient to
reinitialize the machine as an NIS+ client. (If you wish, you can use nistbladm to create an alias for the machine's old name in the hosts tables.)
If necessary, replace the user's credentials in the cred table.