Our users and groups LDAP configuration is working.

Our server is using LDAP to store users and groups.

# /etc/nsswitch.conf :
passwd:         compat ldap
group:          compat ldap
shadow:         compat ldap

But today we added a new group in LDAP, with 3 users, and then, added other users. The 3 users are in the group but not the others.

We can see this by using the "groups " : more precisely, "getent group GROUPNAME" shows the user in the group while "groups " does not show the group for that user... ?!

Therefore I am trying to understand :

  • Is there some kind of cache for groups - LDAP list ?
  • Or is it possible for the synchronization to fail, if yes how to manually re-launch it ?

Sorry not to be more precise in my question, but I really don't see where to start...

P. S. Config files

# /etc/ldap/ldap.conf
URI     ldap://
TLS_CACERT      /etc/ssl/certs/ca-certificates.crt

# /etc/pam_ldap.conf
base dc=ourdomain,dc=ch
uri ldap://
ldap_version 3
rootbinddn cn=admin,dc=ourdomain,dc=ch
pam_password crypt
  • P. S. After some time, now everything is OK. But I am still puzzled about what happened and would be happy if someone could answer that question. And I am sure it could help other people
    – db_ch
    Feb 2, 2017 at 11:46
  • 1
    any chance you logged out and in again in the meantime?
    – jopasserat
    Feb 2, 2017 at 14:41
  • @jopasserat: I tried that (logout and login) because I know it can play a role but without success.
    – db_ch
    Feb 2, 2017 at 16:30
  • there is also newgrp(1) in addition to the logout dance
    – thrig
    Feb 2, 2017 at 19:54

2 Answers 2


pam_ldap and nsswitch have no caching mechanisms, but nscd or sssd may be present on your system that implement cache.

To invalidate / flush nscd groups cache use:

sudo nscd --invalidate=group

To invalidate / flush sssd groups cache use:

sudo sss_cache -G
  • Yes nscd is present on the system. If it happens again in the future I will check with you proposed answer.
    – db_ch
    Feb 2, 2017 at 16:31
  • Ok in fact I tried your solution with the same scenario on another user and it seem to have worked !
    – db_ch
    Feb 2, 2017 at 16:33
  • 2
    I think the command is actually sss_cache
    – gerard
    Sep 27, 2018 at 19:42
  • I found that even sss_cache -E or stop sssd service, getent command still can retrieve info from cache. That is the NSCD cache. nscd --invalidate clear NSCD cache. Thanks.
    – PT Huynh
    Sep 10, 2020 at 9:37
  • My experience in RHEL 6, 7, and up to 8.1 indicates that "sss_cache -E" (or "sss_cache -G") may not work. (Since I run sssd, I don't run nscd or nslcd.) As reported in this open issue at GitHub github.com/SSSD/sssd/issues/4872 the way for the cache to be really cleaned out is to: systemctl stop sssd ; rm /var/lib/sss/db/cache_default.ldb ; systemctl start sssd
    – phzx_munki
    Feb 10, 2021 at 6:45

jopasserat's comment leads to another possible answer.

The groups command doesn't report group memberships of a user. It reports the group ID privileges of the current process. It only uses NSS to convert numeric group IDs to names.

When a user logs in, the group memberships are obtained from NSS, and the setgid and setgroups system calls are used to give the correct privileges to the user's initial process. All processes descended from there inherit the same privileges (except when a set-id program is executed).

If the configured privileges change, while the user is logged in, the existing processes are not affected. You have to log out and in again to gain privileges, and if you're trying to revoke privileges, you have to kill all of the user's processes to finish the job.

nscd and such can add extra layers of cache to worry about, but pre-existing user processes are effectively a privilege cache that is present in all configurations.

  • Sorry but I tried that before (login and logout).
    – db_ch
    Feb 2, 2017 at 16:34
  • Your solution may although help other people in the future having a similar problem
    – db_ch
    Feb 2, 2017 at 16:34
  • I'm surprised to hear that getent didn't agree with a fresh login!
    – user193597
    Feb 2, 2017 at 16:36
  • Yes I can confirm it was the case. The solution was solved with "nscd --invalidate=group"... I can reproduce the case (I just did again before commenting).
    – db_ch
    Feb 2, 2017 at 16:38
  • Maybe getent bypasses nscd then. It looks like I don't really know what's going on. I'll leave this answer here anyway, since it provides another reason getent might disagree with groups
    – user193597
    Feb 2, 2017 at 17:10

You must log in to answer this question.

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