I encountered a strange problem today while installing the "passenger" web server on a centos system.

The server was failing to set the GID for a directory that it created, even though it was trying to use the group of the current user. The error is below:

Cannot change the directory '/tmp/passenger.spawn.XXXX6rOcmE/envdump' its UID to 1005 and GID to 100: Operation not permitted (errno=1)

After some digging, I discovered that the problem was that there were two groups with the same name, but different GIDs, as seen in the command below:

$ getent group | grep users

After renaming one of the two groups, the problem was fixed.

So my question is this: according to specifications, is it valid for two groups on the same system to have the same name, or is it not?

The reason is that if it is valid, I plan to submit a bug report for passenger since it couldn't handle that situation, if it is not valid then a bug should be reported to centos.

2 Answers 2


Forget specifications, and consider what would happen in practice. The main thing to note is that the filesystem permissions, don't contain a group name, they only contain the integer group id. (The underlying system call is chown(), you can see the gid_t in the argument list there.)

So, chgrp, chown, or whatever tool used to change the group of the directory, has to find out the correct group id from the name the user gave. When you have two with the same name, there's no way to tell which one was meant. With the groups in /etc/group, you're likely to always get the first one though. Some other ways of storing users and groups might not even be able to store the same name twice, e.g. if it's used in an LDAP DN or other similar primary key.

Assuming the first line takes effect, the named group users would resolve to GID 100, and if the user in question was asdf, they'd be a member of group 1001, but not of group 100, and the chgrp would fail.

  • 1
    Then this means the developers of passenger somewhere used the group name to identify the group instead of the id, if they had only used ids there would not be any problem, correct?
    – user000001
    Commented Oct 8, 2020 at 16:31
  • 2
    @user000001, well, it looks like that to me.
    – ilkkachu
    Commented Oct 8, 2020 at 16:41

No, it’s not valid; I’m not sure it’s spelled out explicitly in POSIX, but the chgrp definition assumes that a single group id (if any) exists for a given group name:


A group name from the group database or a numeric group ID. Either specifies a group ID to be given to each file named by one of the file operands. If a numeric group operand exists in the group database as a group name, the group ID number associated with that group name is used as the group ID.

In a similar fashion, getgrnam only handles a single group for a given name.

(Technically, things work if multiple group names point to the same id, although the specifications don’t really allow this; but the inverse isn’t true.)

  • So this means that it is a bug in centos that allowed the groups to be created with the same name?
    – user000001
    Commented Oct 8, 2020 at 16:28
  • 1
    Not necessarily, it very much depends on how the group was created. If a CentOS-provided tool was used to create both groups, then yes, this could be a bug in that tool; but the groups might have been created by directly modifying the file... Commented Oct 8, 2020 at 16:35
  • Unfortunately I don't know the answer to that, I only have a user account on that server, it was set up by someone else.
    – user000001
    Commented Oct 8, 2020 at 16:36

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .