Real utility of idmapd

[Kevin Coffman]

On 3/22/07, Guillaume Rousse <Guillaume.Rousse at inria.fr> wrote:
> Kevin Coffman wrote:
> > 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?
> No. ls -l on the server attributes it to nobody, because uid 501 doesn't
> exist there. It should have been 500 if the mapping succedeed.

Then I am confused on where the 501 came from.