On Mon, 8 Oct 2012 10:26:47 -0500 Malahal Naineni <malahal@xxxxxxxxxx> wrote: > J. Bruce Fields [bfields@xxxxxxxxxxxx] wrote: > > On Mon, Oct 08, 2012 at 08:54:52AM -0500, Malahal Naineni wrote: > > > NeilBrown [neilb@xxxxxxx] wrote: > > > > Mount with NFSv4 and it takes about the same. However: > > > > > > > > ..... > > > > drwxr-xr-x 2 4294967294 root 4096 Oct 8 16:19 2974 > > > > drwxr-xr-x 2 4294967294 root 4096 Oct 8 16:19 2975 > > > > drwxr-xr-x 2 4294967294 root 4096 Oct 8 16:19 2976 > > > > drwxr-xr-x 2 4294967294 root 4096 Oct 8 16:19 2977 > > > > drwxr-xr-x 2 4294967294 root 4096 Oct 8 16:19 2978 > > > > drwxr-xr-x 2 u2979 root 4096 Oct 8 16:19 2979 > > > > drwxr-xr-x 2 u2980 root 4096 Oct 8 16:19 2980 > > > > drwxr-xr-x 2 4294967294 root 4096 Oct 8 16:19 2981 > > > > drwxr-xr-x 2 4294967294 root 4096 Oct 8 16:19 2982 > > > > drwxr-xr-x 2 4294967294 root 4096 Oct 8 16:19 2983 > > > > drwxr-xr-x 2 4294967294 root 4096 Oct 8 16:19 2984 > > > > drwxr-xr-x 2 4294967294 root 4096 Oct 8 16:19 2985 > > > > drwxr-xr-x 2 4294967294 root 4096 Oct 8 16:19 2986 > > > > .... > > > > > > > > > > > > tcpdump shows the server is returning the write stuff, but something if going > > > > wrong on the client. I've tried unmounting/remounting and killing/restarting > > > > rpc.idmapd. > > > > > > As you know 4294967294 is (-2, nfs nobody), I have seen this issue with NFS > > > server sending numeric ids by default in AUTH_SYS (commit > > > e9541ce8efc22c233a045f091c2b969923709038), but the client can't handle > > > them (lack of commit 5cf36cfdc8caa2724738ad0842c5c3dd02f309dc in client > > > code). > > > > > > I hand patched server commit, but my client was an older one. That is > > > how I got into my issue. Not sure, if you are running into a similar > > > issue. > > > > Oh, could be--but then why would some of the id's still be mapped > > correctly? > > Wild guess, those objects are created by client and didn't get their > attributes updated yet from server??? > > FYI, a co-worker here had RHEL6.3 server and RHEL6.2 client that > exhibited this nobody issue with NFSv4. > > Regards, Malahal. I think the original cause of my problem was that I had inconsistent settings for 'Domain' in 'idmapd.conf'. That seems to have resulted in 'nobody' entries being cached which I now cannot flush. I'm running a 3.5 kernel on the client, so the issues you mentioned won't be affecting me. Thanks, NeilBrown
Attachment:
signature.asc
Description: PGP signature
