I have a bunch of machines which authenticate via NIS to a central server. I just bought a new CentOS 6.2 client machine, and it can't authenticate.

The following is a list of the classics people get wrong/forget when dealing with NIS:

1) The client machine can ping the server (and ssh in)

Tested using

    ping swordfish 

    ping <ip address>

Both of which generate an appropriate response

2) A ypbind process is running on the client

Tested by doing

ps -e | grep ypbind
3172 ?        00:00:00 ypbind

3) /etc/yp.conf is formatted correctly and contains the correct details

4)The firewall is off So that's hopefully not the problem

5) The service starter thinks everything is OK

    /sbin/service ypbind restart

    Shutting down NIS service:                                 [  OK  ]
    Starting NIS service:                                      [  OK  ]
    Binding NIS service:
    .....                                                      [  OK  ]

The Problem

  • There's no RPC binding as far as I can tell

    /usr/sbin/rpcinfo -p # no ypbind programs
  • There are no binding files in /var/yp/binding/
  • If I view the message log in /var/logs/messages then the following type of report is generated every time I restart the ypbind service

    Sep  7 14:21:34 localhost ypbind: NIS domain: whaleshark, NIS server:

Where whaleshark is the name of the NIS domain, but apparently it has no info on the NIS server? Running ypwhich yields;

ypwhich: Can't communicate with ypbind

Any thoughts or steps I could take would be greatly appreciated!

  • I'm voting to close this question as off-topic because it is related to insecure technology that should not be deployed in a production environment. (NIS) – Andrew B Mar 22 '15 at 18:16
  • @AndrewB I don't believe it is impossible to deploy NIS in a secure fashion. I just think it is very hard. Many times recommending an alternative is the right thing to do. – kasperd Mar 22 '15 at 20:56
  • 1
    @kasperd Agreed, I discussed this on meta and we worked out where my thought process was wrong. I'll flag this for reopening if it gets closed. – Andrew B Mar 22 '15 at 20:58

Ha - I've been trying to figure this out for hours, but just realized the NetworkManager daemon is running, which apparently is blocking when the network interfaces are set to not use the NetworkManager.

Simply running

service NetworkManager stop

And then restarting fixed everything. Hopefully this will help other people out - I saw a bunch of similar looking symptoms online but no-one mentioned the NetworkManager at all.

  • This fixed my NIS problem with CentOS 6 running as a Docker container. service NetworkManager stop && service ypbind restart – eisbaw Jul 13 '15 at 17:02
  • Same here. I was looking for a while and would've never thought of checking to see if NM was running. – Bratchley Aug 17 '15 at 15:12
  • Running the command service NetworkManager stop on my centos 6 nis client did fix the problem, thanks. – ollydbg23 Mar 9 '18 at 9:54

I have faced the same issue, and stopping networkmanager didnt help. After trying out different tricks, i found an interesting workaround. in my case when there was a process dbus-daemon and due to some reason it was consuming lot of CPU, and as soon as i stopped the dbus-daemon process and restarted ypbind service it worked. Please give it a try this, if nothing works. Hope it is helpful !


Try this command before starting ypbind service:

authconfig --update --nisdomain=<nis domain name> --nisserver=<nis server name> --enablenis

You stop the NetworkManager and start ypbind to let ypbind get the binding files. You can start the NetworkManager once it has got the binding files.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.