Re: Inconsistency when mounting a directory that 'world' cannot access.

[NeilBrown <neilb@suse.de>]

[-- Attachment #1: Type: text/plain, Size: 2523 bytes --]

On Mon, 8 Oct 2012 10:26:47 -0500 Malahal Naineni <malahal@us.ibm.com> wrote:

> J. Bruce Fields [bfields@fieldses.org] wrote:
> > On Mon, Oct 08, 2012 at 08:54:52AM -0500, Malahal Naineni wrote:
> > > NeilBrown [neilb@suse.de] 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 #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 828 bytes --]