Bug#758870: nfs-common: nfs v4: uid/gid lookup fails for some of the users
Hi Iustin,
On 2014-09-04 19:11, Iustin Pop wrote:
[...]
>
> Just another datapoint: this is different from my case. No new users
> created, randomly new files get -1 for a while, after which the correct
> UID is listed.
No, this is not different: all new users get new files, which have never
been served by the nfs server before. With me, "a while" might last
forever for some identities.
When I create files or dirs, they may be owned by the infamous -2
(4294967294), regardless _where_ I created them (i.e. through nfs or
locally on the filesystem.
You report that after a while the currect uid and gid are listed. Same for
me, but sadly not always, some identities get stuck on 4294967294
"forever".
I'm curious if we have any differences in our setups:
- Do you also have a mixture of wheezy and jessie systems? Is your nfs
server also on a wheezy system? Are your clients both jessie and wheezy
systems?
- Did you see any changes in the behaviour of the wheezy clients after
the jessie clients mounted?
- Do you have inet6 entries in /etc/netconfig enabled on the jessie
clients (which is the default)?
- Did you change /etc/idmapd.conf?
- Did you change or add any files in /etc/request-key.d/ ? (small test:
rename the id_resolver file, and suddenly _all_ identities are
4294967294)
- Is the serving filesystem XFS formatted?
- Is NIS involved? Or LDAP? (A small test by copying the passwd, shadow
and group entries to the client system: everything is ok).
- Do you use nsswitch to resolve identities (uid/gid)?
- Does your client run a name service caching daemon (nscd or unscd)?
- Did you see nobody/nogroup (65534/65534) identities too?
Just to make sure: this is nfs v4 (v4.0) only. Mounting with nfs version 3
over tcp works fine.
Regards,
Piet
Reply to: