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

[David Barrett <dbarrett@quinthar.com>]

Wow, great observation: doing a "ls" of /etc/group and /etc/passwd fixes 
it.  How incredibly strange:

[root@XXXX svn]# chroot staging/db
id: cannot find name for group ID 0
id: cannot find name for group ID 1
id: cannot find name for group ID 2
id: cannot find name for group ID 3
id: cannot find name for group ID 4
id: cannot find name for group ID 6
id: cannot find name for group ID 10
I have no name!@XXXX:/# ls /etc/group /etc/passwd
/etc/group  /etc/passwd
I have no name!@XXXX:/# exit
[root@XXXX svn]# chroot staging/db
root@XXXX:/#

Anyway, it's fantastic to have a workaround.  Thanks a million!

Also, here's the output of "id" from a broken chroot; I don't actually 
know if this fixes it -- I tried the "ls" trick and that did it, so I 
don't know if "id" will fix it, too.

I have no name!@XXXX:/# id
uid=0 gid=0 groups=0,1,2,3,4,6,10

Finally, fixing one chroot neither fixes nor breaks the other -- they 
seem entirely independent.  (Great question, though.)

So, the next time I see it I'm going to see if "id" fixes it by itself. 
 I'm also going to read up more on the nscd and see if tweaking that 
helps.  It's a little slow going as it seems to take a long time for 
this problem to re-appear; perhaps I can tweak nscd to force it to 
happen more frequently, and thus better figure out how to make it not 
happen it all.

Thanks for all your help!

-david


Daniel Burrows wrote:
> 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