|
|
When most machines on the network appear to be behaving normally, but one client cannot receive NIS services, that client may experience many different symptoms. For example, some commands appear to operate correctly while others terminate with an error message about the unavailability of NIS. Other commands limp along in a backup-strategy mode particular to the program involved. Still other commands or daemons crash with obscure messages or no message at all. Here are messages a client in this situation may receive:
# ypcat myfile
ypcat: can't bind to NIS server for domain domainname.
Reason: can't communicate with ypbind.
# /usr/sbin/yppoll myfile
yppoll: Sorry, I can't make use of the NIS. I give up.
On the problem client,
run ls -l on a directory containing files owned by many users,
including some not in the client's
/etc/passwd file--for example /home.
If the resulting display lists file owners not in the local /etc/passwd
as numbers, rather than names, NIS is not working.
These symptoms usually indicate that the client's ypbind process is not running. Run ps -eaf and check for ypbind. If you do not find the ypbind process, log in as NIS administrator and start it by entering /usr/lib/netsvc/yp/ypbind. NIS problems should disappear.