I've been trying to configure a new system we have on our network to run NFS but I'm running into some issues after the configuration. When I do a service nfs start I get this:


Starting NFS services: [ OK ]
Starting NFS quotas: Cannot register service: RPC: Authentication error; why = Client credential too weak
rpc.rquotad: unable to register (RQUOTAPROG, RQUOTAVERS, udp).
[FAILED]
Starting NFS daemon: rpc.nfsd: writing fd to kernel failed: errno 13 (Permission denied)
rpc.nfsd: writing fd to kernel failed: errno 13 (Permission denied)
rpc.nfsd: unable to set any sockets for nfsd
[FAILED]

I've checked to make sure that the rpcbind daemon is running and nfslock. Is there something I'm missing here? I've done some googling but everything talks about checking to make sure that portmap is running and it doesn't look like RHEL6 even comes with it anymore. Any help would be much appreciated.

Found out the issue I was having. You have to add the line:

ALL:127.0.0.1

to hosts.allow in order to start the nfs daemon.

It might also be likely to selinux being enabled as well. You shouldn't have to use hosts.allow or hosts.deny in order for daemons or services to work, that would be an admin nightmare.

The first thing I do if it's not disabled from a kickstart install is, disable selinux, it does more damage than good. Most people don't have the time to configure a system with selinux enabled.

I realize this is an older thread, but Google finds it among the top 3 results and people are still discovering the nfs service error. Even Red Hat's RHN's fix didn't work.

As of December 2013 on a RHEL 6.4 (x64), and patched as of November 2013, the only solution was changing the permissions on the tcp_wrapper config files. Because we had secured the box pretty heavily, we had permissions of 640 on /etc/hosts.allow and /etc/hosts.deny, both owned by root:root. We did try given these files different group ownership nothing corrected the issue when nfs started.

Once we put the perms back to "out-of-the-box" (644) the nfs (rquotad) service started up as expected. Or if we moved the hosts.allow/deny out of the way entirely.

What a pain that was to figure out. The selinux logs may have helped if I had looked sooner.

Now if we had left selinux in enforcing mode this MAY have not been an issue. I still have to test that theory.

Good luck.