View Full Version : Problem with .bashrc

8th December 2014, 09:58 PM
Hello everybody,
I am using Fedora 20 and I was trying to color my name on the command line.
While playing with the .bashrc file, I might have done something wrong.

If I open a terminal I get now the following

id: cannot find name for group ID 200

but, fortunately, everything works without any problem.

My .bashrc contains the following

# .bashrc

# Source global definitions
if [ -f /etc/bashrc ]; then
. /etc/bashrc

# Uncomment the following line if you don't like systemctl's auto-paging feature:

It looks like is a problem with the bashrc file in /etc/ directory, but I am pretty sure that I haven't touch that file, in fact the last modification is June 2013, anyway I also attach the bashrc (with a .txt extension just because otherwise I didn't manage to upload it)

Do you know what could be wrong? Having a look at other .bashrc in other computers it looks like there is nothing wrong in my file.
Fortunately everything works fine, but is a bit annoying to have that string everytime I open a terminal...

Thanks a lot for any help!:)


9th December 2014, 12:47 AM
As I understand it linux will run .bashrc (where aliases and functions usually go) each time you start a new shell and .bash_profile (where environment variables usually go) when you login or start a login shell. So for coloured prompt I put a colour variable in .bash_profile e.g.

PS1="\[\e[32;1m\][\u@\h \W]$ \[\e[0m\]"

which gives me a green prompt. I don't touch the corresponding /etc files.

9th December 2014, 01:38 AM
The problem you have is that there is a file with group id of 200, but there is no entry in the /etc/group file for that GID.

9th December 2014, 05:27 PM
The problem you have is that there is a file with group id of 200, but there is no entry in the /etc/group file for that GID.

Yes I agree, but it's strange that that file hasn't been touched by me and before there was any problem...

Ahmad Samir
9th December 2014, 06:03 PM
What's the output of 'id' run as user?

10th December 2014, 01:12 AM
Yes I agree, but it's strange that that file hasn't been touched by me and before there was any problem...

That file doesn't have to have been touched.

A groupid on a file could have been changed...

10th December 2014, 09:45 AM
Thanks all of you.
The output is

uid=5325(barducci-local) gid=200(theorie) groups=200(theorie),10(wheel),100(users)

Strange enough, this morning I turned on the computer and that message is not there anymore... o.O

Ahmad Samir
10th December 2014, 03:00 PM
Where's group 200 coming from? a group defined via e.g. LDAP? (I've never used LDAP so don't know much about it if I am honest).

11th December 2014, 05:27 PM
To be honest I don't really now. Is the computer that my Institution (University) gave me for work, and theorie means theorie section (to which I belong), but I didn't set any of those...

Ahmad Samir
11th December 2014, 05:50 PM
That could be it, network-based login, so your problem looks like http://unix.stackexchange.com/questions/54953/error-message-id-cannot-find-name-for-group-id-after-logging-in

13th December 2014, 11:53 AM
Thank you, indeed yes. But, mysteriously, the problem is gone...

Ahmad Samir
13th December 2014, 01:36 PM
My best guess would be that whatever network-login mechanism your university uses worked correctly when you rebooted the machine, or there was a transient problem with it when you saw the problem... etc.

13th December 2014, 01:52 PM
I just noticed that you are using Fedora 20....

If it is using network name services, then it is very likely that the service wasn't running yet.

Ever since Fedora went to systemd for startup, it has had problems with services starting properly. And the problem isn't that they can't start, just that it isn't consistent. Sometimes works, sometimes not. Just adding a new service (or removing one) changes the order things start in because systemd uses a thundering herd scheduling for a LOT of services.

For instance, most things (like the GUI login) depend on the network to be up before they get started...

But then, things like a local caching name service (or LDAP service) also depend on that (as does the GUI). Once the network is "up" sometimes the naming services will be started AFTER the GUI - which can cause problems. Or the network really isn't quite ready (DHCP can take a while, but systemd assumes the network is ready when NetworkManager notifies systemd - but doesn't know that dhclient may have had to wait...), thus ldap names failed... (after all it may have to wait for a caching name server to be running... which may also be delayed).

16th December 2014, 08:31 AM
Thanks a lot for the explanation!