Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

The Problem: CentOS does not seem to look at secondary groups when using ACL's on a folder or file

Scenario: CentOS 6 basic install, uses LDAP accounts to authenticate users. I am trying to setup fairly complex permissions on some folders. I have ensured that the file system is mounted with ACL support and determined that LDAP users are able to log in correctly.

Steps to Reproduce: As a test I have a simple folder structure. The folder test1 is owned by root and has 770 permissions, I have added another group to that folder setfacl -m g:testgroup:rwx test1/ The getfacl output for the folder looks like this:

getfacl: Removing leading '/' from absolute path names
# file: share/test1/
# owner: root
# group: root

The user andrew belongs to the domain group and testgroup as shown by groups andrew. The group domain is the users primary group. If the user andrew tries to read anything located in test1 a permission denied error was shown. If however the users primary group is changed to testgroup the user can then interact with the contents of the folder.

Can anybody tell me what is going on here and if there is a way to get the expected behaviour?

EDIT This appears to be a problem related to LDAP. I just tested using local user accounts and everything works as expected.

share|improve this question
Have you done a "getent group" and verified no group is actually there TWICE and DIFFERENT? Also, check "id" for the users involved that group lists have not been truncated due to implementation limits (this used to be a metric b.... with NIS and might also be a problem with your LDAP implementation). Sorry for being able to offer only generic advice there... – rackandboneman May 8 '12 at 22:43
@rackandboneman 'getent group' does not have any groups repeated. And 'id' of a user shows they belong to the relevant groups, nothing appears to be truncated. – kaptk2 May 9 '12 at 14:17
up vote 3 down vote accepted

As you say this problem is related to the use of LDAP for user information. Your Centos6 machine is configured in a way that is incompatible with the LDAP server, so that when it tries to get the list of supplementary groups the user belongs to, it doesn't find anything.

Unfortunately there are several standards for how to interpret LDAP attributes relating to POSIX groups - rfc2307, rfc2307bis, IPA

Centos 6 uses SSSD for managing interwork with remote directories and authentication databases. The default settings for SSSD are to use rfc2307.

You will probably find your LDAP server is using rfc2307bis. We have a Centos 5 directory server, it was configured by default for rfc2307bis. As a further complication, our C5 directory was using the attribute 'uniqueMember' instead or 'member' for group members.

To fix it, edit /etc/sssd/sssd.conf and add the following lines:

ldap_schema = rfc2307bis
ldap_group_member = uniqueMember

You might also like to refer to the following:

share|improve this answer
Bingo, we have a winner! Thanks for the answer – kaptk2 Sep 24 '12 at 14:44

Have you tried looking at the numeric ids of both the groups the user belongs to, and the ACL of the directory? Try getfacl -n test1 and compare the groups listed with the output of id -G andrew. See if there is any discrepancy there and try resolve it.

share|improve this answer
The groups do match up, as do the numeric ID's so I don't think that is the root issue. – kaptk2 May 14 '12 at 14:53
Could it be that the user belongs to too many groups? Is this reproducible with a user that is a member of only a couple of groups? – chutz May 18 '12 at 17:14

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.