Re: Any idea why chroot temporarily "cannot find name for group ID 0"?

[Daniel Burrows <dburrows@debian.org>]

On Mon, Jun 30, 2008 at 01:12:34PM -0700, David Barrett <dbarrett@quinthar.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
configured?

> 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
the chroots.


  I think an strace of a failing command (e.g., "id") would be very
interesting.

  Daniel