Troubleshooting NIS Issues That Affect a Single Client

Language:

If only one or two clients are experiencing symptoms that indicate NIS binding difficulty, the problems probably are on those clients. However, if many NIS clients are failing to bind properly, the problem probably exists on one or more of the NIS servers. See Troubleshooting NIS Issues That Affect Multiple Clients.

The following are common NIS issues that affect a single client:

ypbind daemon not running on the client

One client has problems, but the other clients on the same subnet are operating normally. On the problem client, run the ls –l command on a directory that contains files that are owned by many users (such as /usr), including files that are not in the client /etc/passwd file. If the resulting display lists file owners who are not in the local /etc/passwd file as numbers rather than names, the NIS service is not working on the client.

These symptoms usually indicate that the client's ypbind process is not running. Verify whether the NIS client services are running as follows:
```
client# svcs \*nis\*
STATE          STIME    FMRI
disabled       Sep_01   svc:/network/nis/domain:default
disabled       Sep_01   svc:/network/nis/client:default
```
If the services are in a disabled state, log in and become the root role, then start the NIS client service as follows:
```
client# svcadm enable network/nis/domain
client# svcadm enable network/nis/client
```
Missing or incorrect domain name

One client has problems and other clients are operating normally, but the ypbind daemon is running on that client. In this case, the client might have an incorrectly set domain.

Run the domainname command on the client to determine which domain name is set:
```
client# domainname
example.com
```
Compare the output with the actual domain name in the /var/yp directory on the NIS master server. As shown in the following example, the actual NIS domain is shown as a subdirectory in the /var/yp directory:
```
client# ls -l /var/yp
-rwxr-xr-x 1 root Makefile
drwxr-xr-x 2 root binding
drwx------ 2 root example.com
```
If the domain name that is displayed in the output of the domainname command on the client is not the same as the server domain name that is listed as a subdirectory in the /var/yp directory, the domain name in the config/domain property of the nis/domain service is incorrect. Reset the NIS domain name. For instructions, see How to Set a Machine’s NIS Domain Name in Working With Oracle Solaris 11.2 Directory and Naming Services: DNS and NIS .

Note - The NIS domain name is case-sensitive.
Client not bound to server

If your domain name is set correctly and the ypbind daemon is running, yet commands still hang, make sure that the client is bound to a server by running the ypwhich command. If you have just started the ypbind daemon, then run the ypwhich command. You might need to run the ypwhich command several times. Typically, the first time you run the command, it reports that the domain is not bound. The second time you run the command, it should proceed normally.
No server available

If your domain name is set correctly and the ypbind daemon is running, but you receive messages indicating the client cannot communicate with the server, check the following:
- Does the client have a /var/yp/binding/domainname/ypservers file that contains a list of servers to bind to? To view the selected NIS servers, use the svcprop –p config/ypservers nis/domain command. If not, run the ypinit –c command to specify which servers this client should bind to, in order of preference.
- If the client does have a /var/yp/binding/domainname/ypservers file, are there enough servers listed, in case one or two servers become unavailable? To view the selected NIS servers, use the svcprop –p config/ypservers nis/domain command. If not, add additional servers to the list by running the ypinit –c command.
- Do the selected NIS servers have entries in the /etc/inet/hosts file? To view the selected NIS servers, use the svcprop –p config/ypservers nis/domain command. If these hosts are not in the local /etc/inet/hosts file, add the servers to the hosts NIS maps and rebuild your maps by running the ypinit –c or ypinit –s command. For information, see Working With NIS Maps in Working With Oracle Solaris 11.2 Directory and Naming Services: DNS and NIS .
- Is the name service switch set up to check the system's local hosts file, in addition to NIS? For more information, see Chapter 2, About the Name Service Switch, in Working With Oracle Solaris 11.2 Directory and Naming Services: DNS and NIS .
- Is the name service switch set up to check files first for services and then rpc?
ypwhich displays are inconsistent

If you run the ypwhich command several times on the same client, the resulting display varies because the NIS server changes. This behavior is normal. The binding of the NIS client to the NIS server changes over time when the network or the NIS servers are busy. Whenever possible, the network becomes stable at the point when all clients receive an acceptable response time from the NIS servers. As long as the client receives the NIS service, it does not matter where the service comes from. For example, one NIS server can receive NIS services from another NIS server on the network.

What to do when server binding is not possible

In extreme cases where local server binding is not possible, use the ypset option with the ypbind command to temporarily allow binding to another server on another network or subnet, if available. Note that to use the –ypset option, you must start the ypbind daemon by using either the –ypset or –ypsetme option. For more information, see the ypbind(1M) man page.

# /usr/lib/netsvc/yp/ypbind -ypset

For another method, see Binding to a Specific NIS Server in Working With Oracle Solaris 11.2 Directory and Naming Services: DNS and NIS .

Caution - For security reasons, using the –ypset or –ypsetme option is not recommended. Only use these options for debugging purposes under controlled circumstances. Using the –ypset or –ypsetme option can result in serious security breaches. While the daemons are running, anyone can alter server bindings, which can permit unauthorized access to sensitive data. If you must start the ypbind daemon by using either of these options, kill the ypbind process after you have corrected the problem, then restart it without specifying these options. Restart the ypbind daemon as follows:

# svcadm enable -r svc:/network/nis/client:default

See the ypset(1M) man page.

ypbind daemon crashes

If the ypbind daemon crashes almost immediately each time you start it, look for a problem in the svc:/network/nis/client:default service log. Check for the presence of the rpcbind daemon as follows:
```
% ps -e |grep rpcbind
```
If the rpcbind daemon is not present, does not stay up, or behaves strangely, check the svc:/network/rpc/bind:default log file. For more information, see the rpcbind(1M) and rpcinfo(1M) man pages.

You might be able to communicate with the rpcbind daemon on the problematic client from a system that is functioning normally.

Run the following command from a functioning system:
```
% rpcinfo client
```
If the rpcbind daemon on the problematic system is fine, the following output is displayed:
```
program	version	netid	address	service	owner
...
100007    3    udp6      ::.191.161          ypbind     1
100007    3    tcp6      ::.135.200          ypbind     1
100007    3    udp       0.0.0.0.240.221     ypbind     1
100007    2    udp       0.0.0.0.240.221     ypbind     1
100007    1    udp       0.0.0.0.240.221     ypbind     1
100007    3    tcp       0.0.0.0.250.107     ypbind     1
100007    2    tcp       0.0.0.0.250.107     ypbind     1
100007    1    tcp       0.0.0.0.250.107     ypbind     1
100007    3    ticlts    2\000\000\000       ypbind     1
100007    2    ticlts    2\000\000\000       ypbind     1
100007    3    ticotsord 9\000\000\000       ypbind     1
100007    2    ticotsord 9\000\000\000       ypbind     1
100007    3    ticots    @\000\000\000       ypbind     1
...
```
If no addresses are displayed (your system will have different addresses), the ypbind daemon was unable to register its services. Reboot the system and run the rpcinfo command again. If the ypbind processes are there and they change each time you attempt to restart the NIS service, reboot the system, even if the rpcbind daemon is running.