Re: Any idea why chroot temporarily "cannot find name for group ID 0"?
On Mon, Jun 30, 2008 at 01:12:34PM -0700, David Barrett <email@example.com> was heard to say:
> Basically, I go into staging/www, and it works fine. Then I go into
> staging/db, and it has the problem. I immediately check the group
> permissions, and note that now group IDs are being resolved to group
> names, but user IDs aren't getting resolved. I then check the passwd
> permissions, and note that both user and group names are now working. I
> go right back to the group file, and now group and usernames are working
> fine. I exit the broken DB chroot, and re-enter just fine.
Just out of curiosity, does the chroot that *was* working continue to
work after this?
If you run, e.g., "id" a few times when it's broken, does it continue
to be broken? And although I can't imagine why this would be the case,
does the problem consistently go away for, e.g., passwords after you
"ls" the password file? I notice that this happened in both of your
last two examples: your problems with each file went away as soon as you
listed it. Is there anything unusual about how your filesystems are
> As for nsswitch.conf, here it is: I haven't changed it, but I'm not
> familiar with the file so I don't know if it's right or not:
That looks right. The main concern would be if you had done something
like fetching user information from LDAP, which would be another place
for bugs to hide.
> As for nscd... Aha! This is a good candidate: it turns out I *do* have
> this installed on the host system. I don't know anything about this;
> I'll need to read up on it.
nscd caches lookups of things like uid <-> name mappings. I've had
various problems in the past, which I won't detail because I can't
remember them in detail, and I wouldn't recommend installing it unless
you need to (mostly if you're using something like NIS or LDAP). This
looks like the sort of gremlin that nscd could cause.
However, I don't think I needed to ask whether you had it installed on
the host system: it looks like it communicates via a Unix-domain socket
in /var, so it wouldn't be able to interfere with what's happening in
I think an strace of a failing command (e.g., "id") would be very