Re: NFS drive uids/gids completely broken- for a little while

[Mike Kupfer <m.kupfer@acm.org>]

<briand@aracnet.com> wrote:

> [   42.426886] NFS: v4 server <name> does not accept raw uid/gids. Reenabling the idmapper.

Here's some background information:

In NFSv3, uids and gids are represented as integers.  In NFSv4, they are
strings.  The original specification called for strings of the form
"id@domain", and typically a daemon on both the client and server would
map between that string and the integer IDs that are used natively on
that host.

But it proved to be hard to make this all work seamlessly out of the
box.  The daemon wouldn't be able to do the mapping for whatever reason,
and people would frequently find their files owned by "nobody" (or some
moral equivalent).

So the most recent version of the spec (RFC7530) allows for the use of
integers encoded as strings.  For example, ID 12345 would be sent as the
string "12345".  Recent versions of Linux support this, but older
versions do not.  I don't remember when support was added.

So, based on that log message, I'm guessing that this is what's
happening: the client attempts to use stringified integers, rather than
"id@domain".  It gets a response back from the server that indicates
that the server does not support stringified integers, so the client
falls back to the old "id@domain" syntax.

If my guess is correct, possible remedies are

- change the mount to NFSv3
- upgrade the server

I'd also see if there are updates available for the client.  It really
ought to do a better job of recovering in this case.  I don't see a way
to configure the client to always use id@domain, but maybe I'm missing
something.

> What's _really_ weird is that my top-level user directory is fine,
> it's a sub-directory that's giving me uid/gid of  4294967294
> 4294967294

This is probably due to attribute caching on the client.  Did you look
at the top-level directory first, or after the one that shows
4294967294?

mike