Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I have a DRBD partition mounted get auto-mounted using Linux-HA, then it sets up a bind and shares the directory via NFS. This shares out a directory for user home directories.

Some users work fine, most do not and it sits there hanging on mounting their folder. When I do a tcpdump I see:

07:45:16.415649 IP > . ack 976 win 348
07:45:22.705531 IP foo.server.c.2174542926 > 192 getattr [|nfs]
07:45:22.705643 IP > . ack 1985 win 501
07:45:23.703517 IP > foo.server.c.2174542926: reply ok 96 getattr ERROR: Request couldn't be completed in time
07:45:23.703564 IP > . ack 1072 win 348
07:45:25.053519 IP foo.server.c.2191320142 > 192 getattr [|nfs]
07:45:25.053651 IP > . ack 2177 win 501
07:45:26.051473 IP > foo.server.c.2191320142: reply ok 96 getattr ERROR: Request couldn't be completed in time
07:45:26.051522 IP > . ack 1168 win 348
07:45:31.413431 IP foo.server.c.2208097358 > 160 getattr [|nfs]
07:45:31.413556 IP > . ack 2337 win 501
07:45:32.411393 IP > foo.server.c.2208097358: reply ok 76 getattr ERROR: Request couldn't be completed in time

my auto.master looks like:

/home/users   /etc/auto.home  --timeout=60

my auto.home :

*       -fstype=nfs4,rw,nosuid,soft,rsize=8192,wsize=8192

my exports :


my idmapd.conf :


Verbosity = 0
Pipefs-Directory = /var/lib/nfs/rpc_pipefs
Domain =


Nobody-User = nfsnobody
Nobody-Group = nfsnobody

Method = nsswitch

I'm using CentOS 5.4, nfs versions:

nfs-utils-1.0.9-42.el5 nfs-utils-lib-1.0.8-7.6.el5 nfs4-acl-tools-0.3.3-1.el5

share|improve this question
up vote 2 down vote accepted

this turned out to be the clue:

rpc.idmapd[5924]: nfsdcb: id '-2' too big!

the issue was that the default nfsnobody user has a uid of 4294967294 , but on a 64-bit CentOS system it appears to be interpreting this number in a 32-bit context leading to the infamous -2. The fix is to :

  • change nfsnobody user/group to uid/gid 65534 on both client and server
  • chown any files owned by uid 4294967294 on the server to nfsnobody

this resolves the issue

share|improve this answer
I find it ridiculous that Linux distributions didn't just, when they first started making a 64-bit flavor, declare that nfsnobody is 65534 regardless of architecture. – mattdm Feb 2 '11 at 6:30

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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