[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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

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

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!


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

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


Reply to: