If only one or two clients are experiencing symptoms that indicate NIS binding difficulty, the problems probably are on those clients. If many NIS clients are failing to bind properly, the problem probably exists on one or more of the NIS servers. See NIS Problems Affecting Many Clients.
One client has problems, but other clients on the same subnet are operating normally. On the problem client, run ls –l on a directory, such as /usr, that contains files owned by many users, including some not in the client /etc/passwd file. If the resulting display lists file owners who are not in the local /etc/passwd as numbers, rather than names, this indicates that NIS service is not working on the client.
These symptoms usually mean that the client ypbind process is not running. Verify whether the NIS client services are running.
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 as root or assume an equivalent role, and start the NIS client service.
client# svcadm enable network/nis/domain client# svcadm enable network/nis/client
One client has problems, the other clients are operating normally, but ypbind is running on the problem client. The client might have an incorrectly set domain.
On the client, run the domainname command to see which domain name is set.
client7# domainname example.com
Compare the output with the actual domain name in /var/yp on the NIS master server. The actual NIS domain is shown as a subdirectory in the /var/yp directory.
client7# 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 returned by running domainname on a machine is not the same as the server domain name listed as a directory in /var/yp, the domain name specified in the machine's /etc/defaultdomain file is incorrect. Reset the NIS domain name as shown in How to Set a Machine's NIS Domain Name.
If your domain name is set correctly, ypbind is running, and commands still hang, then make sure that the client is bound to a server by running the ypwhich command. If you have just started ypbind, then run ypwhich several times (typically, the first one reports that the domain is not bound and the second succeeds normally).
If your domain name is set correctly, ypbind is running, and you get messages indicating that the client cannot communicate with a server, this might indicate a number of different problems:
Does the client have a /var/yp/binding/domainname/ypservers file containing a list of servers to bind to? If not, run ypinit –c and specify in order of preference the servers that this client should bind to.
If the client does have a /var/yp/binding/domainname/ypservers file, are there enough servers listed in it if one or two become unavailable? If not, add additional servers to the list by running ypinit –c.
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 as described inWorking With NIS Maps.
Is the name service switch set up to check the machine's local hosts file in addition to NIS? See Chapter 2, About the Name Service Switch for more information on the switch.
Is the name service switch set up to check files first for services and rpc? See Chapter 2, About the Name Service Switch for more information about the switch.
When you use ypwhich several times on the same client, the resulting display varies because the NIS server changes. This 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 a point where all clients get acceptable response time from the NIS servers. As long as your client machine gets NIS service, it does not matter where the service comes from. For example, an NIS server machine can get its own NIS services from another NIS server on the network.
In extreme cases where local server binding is not possible, use of the ypset command can temporarily allow binding to another server, if available, on another network or subnet. However, in order to use the –ypset option, ypbind must be started with either the –ypset or –ypsetme options. 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.
Caution - For security reasons, the use of the –ypset and –ypsetme options is not recommended. Only use these options for debugging purposes under controlled circumstances. Use of the –ypset and –ypsetme options can result in serious security breaches because while the daemons are running, anyone can alter server bindings, causing trouble for others and permitting unauthorized access to sensitive data. If you must start the ypbind daemon with these options, after you have fixed the problem you must kill the ypbind process and restart it again without those options.To restart the ypbind daemon, use SMF as follows:
# svcadm enable -r svc:/network/nis/client:default
If the ypbind daemon crashes almost immediately each time it is started, look for a problem in the svc:/network/nis/client:default service log. Check for the presence of the rpcbind daemon by typing the following:
% ps -e |grep rpcbind
You might be able to communicate with rpcbind on the problematic client from a machine operating normally. From the functioning machine, type the following:
% rpcinfo client
If rpcbind on the problematic machine is fine, rpcinfo produces the following output:
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 ...
Your machine will have different addresses. If the addresses are not displayed, ypbind has been unable to register its services. Reboot the machine and run rpcinfo again. If the ypbind processes are there and they change each time you try to restart the NIS service, reboot the system, even if the rpcbind daemon is running.