Real utility of idmapd

[Kevin Coffman]

On 3/22/07, Guillaume Rousse <Guillaume.Rousse at inria.fr> wrote:
> J. Bruce Fields wrote:
> >> >From the logs, the server seems to map ids on name, not names on id:
> >> Mar 20 15:33:52 stalingrad rpc.idmapd[19602]:  Server: (user) id "501"
> >> -> name "nobody"
> >> Mar 20 15:33:52 stalingrad rpc.idmapd[19602]: nfsdcb:
> >> authbuf=oberkampf.msr-inria.inria.fr authtype=group
> >> Mar 20 15:33:52 stalingrad rpc.idmapd[19602]:  Server: (group) id "501"
> >> -> name "nogroup"
> >>
> >> So name-based mapping appears to be working upside down here...
> >
> > The above is expected.  For example, if the client is stat'ing a file,
> > then the server must translate the uid and gid stored in the file's
> > inode into a string name that an NFSv4 client will understand.
> It works on the client, indeed: files owned by uid 501 on the server
> appears to be owned by user of the same name on the client, even if he
> has a different uid there (500).
>
> My point it that on the server (stalingrad), file created from the
> client use wrong uid (501), instead of being correctly mapped to uid 500.

You claim the file is created with the "wrong uid" on the server.
Yet, an "ls -l" on that file on the server and on the client will
result in the same name, right?  Why is that "wrong"?  Eliminating all
this confusion is the reason you really want a unique UID/GID space
and consistent name/ID mapping across all the machines in the nfs
domain.