According to Red Hat docs 'rpcbind' is not required any more:

Because protocol support has been incorporated into the v4 protocol, NFSv4 has no interaction with the portmap, rpc.lockd, and rpc.statd daemons. NFSv4 listens on the well-known TCP port 2049, which eliminates the need for portmap interaction. The mounting and locking protocols have been incorporated into the V4 protocol which eliminates the need for interaction with rpc.lockd and rpc.statd. The rpc.mountd daemon is still required on the server, but is not involved in any over-the-wire operations.

however I'm not able to start NFS demon when 'rpcbind' service is not running:

# service nfs start
Starting NFS services:                                     [  OK  ]
Starting NFS quotas: Cannot register service: RPC: Unable to receive; errno = Connection refused
rpc.rquotad: unable to register (RQUOTAPROG, RQUOTAVERS, udp).
Starting NFS mountd:                                       [  OK  ]
Starting NFS daemon: rpc.nfsd: writing fd to kernel failed: errno 111 (Connection refused)
rpc.nfsd: unable to set any sockets for nfsd

I've disabled NFS v2 and v3:

# grep -v "^#" /etc/sysconfig/nfs

Could you please confirm what services are required/essential on server and client from these listed below (basically I would like to disable services which are not needed):

# rpm -ql nfs-utils | grep 'init.d'
  • Did you configure your firewall to allow nfs ?
    – user9517
    Aug 14, 2013 at 13:01
  • Yes, I can mount NFS exports on client but I wonder why I still need to use rpcbind with v4
    – HTF
    Aug 14, 2013 at 14:03
  • 3
    NFSv4 doesn't require rpcbind. But there are clients and tools around which still depend on that information, for example 'showmount'. Additionally, Linux nfsd uses /proc/fs/nfsd/portlist file to communicate port number to rpcbind, and this file somehow depends on running rpcbind process.
    – kofemann
    Aug 15, 2013 at 7:08
  • I can verify this problem on Debian 7 with kernel 3.3.2 by adding -N 2 -N 3 to rpc.nfsd in the start script and getting the same error "unable to set any sockets for nfsd" Jun 28, 2019 at 8:08

3 Answers 3


This was a bug in NFS server kernel module. It was patched in December 2013.

Starting with kernel 3.14, rpcbind is no longer required to run in-kernel NFS server.

(assuming that server is configured to use only NFSv4 and higher)


You can find more information about that change in this thread:


Therefore, your configuration:


should now work without rpcbind.

When you use only NFSv4, none of these services are required:

  • rpc.idmapd is only required for NFSv4. GSS is also required for Kerberos security. Though both are optional. Nov 23, 2019 at 4:51

The quoted documentation from RedHat was wrong and got fixed by Bug 521215: rpc.mountd still must be used to setup NFSv4, but strictly speaking it is not required to be running after that.

  • nfs: Server for all versions of NFS: v2, v3, v4, v4.1
  • rpcbind/portmapper: Server, strictly only for NFS <= v3. But also for NFS v4 as the Linux Kernel NFS server tries to register itself and fails to start if rpcbind is not running.
  • rpc.mountd: Server, strictly only for NFS <=3. But also for NFS v4 as the Linux Kernel uses it to check, if the connecting client is allowed to connect.
  • nfslock: Server only for NFS <= v3
  • rpc.idmapd: Optional Server (and older Clients) for NFS v4
  • rpc.quotad: Server for using disk quota
  • rpc.statd: Server only for NFS <= v3

When using Kerberos (sec=krb/krb5i/krb5p) the following services are required:

  • rpc.gssd: Client
  • rpc.svcgssd: Server

Please note that even they carry rpc. in their name, they use the Linux kernel internal mechanism rpc_pipef for communication between the Linux kernel and the user space helper; so rpcbind AKA portmapper is not needed for them.


Check rpcbind service. If it stopped working start and then try starting nfs service.

service rpcbind start
service nfs start
  • This answer is very low quality. OP has stated rpcbind was not required since nfsv4. The question has already been answered : it was a kernel bug.
    – bgtvfr
    Aug 14, 2017 at 14:41

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.