On Fri, 2012-05-11 at 09:10 +0200, Jan Zelený wrote:
> > On Fri, 2012-05-11 at 08:38 +0200, Jan Zelený wrote:
> > > I guess SSSD cache is probably the reason why you still have the old
> > > GID. Try running sss_cache -G to invalidate all groups and if you
> > > have queried SSSD for that group in last few minutes, wait for the
> > > client in-memory cache to expire as well (or you can just restart
> > > SSSD).
> >
> > Sounds promising... but I tried that (as well as -U and -N), restarted
> > sssd, logged out and logged back in... and still the user appears to be
> > a member of pulse-access (rather than mock).
>
> And when you run getent group mock, the GID is correct or still wrong?
$ getent group mock
mock:x:989:
That's correct (that is, it's consistent with that's in LDAP); but it
was correct before, too.
Ah, sorry for that, I guess I misunderstood.
When I return to the beginning: first of all I'm not sure what do you mean by
your two installations having different GID for group mock - if they both use
SSSD + the LDAP server, they should both have the same GID.
One thing I'm also curious about is if the user is actually LDAP user or local
user. If it's a local user, I'd say that might be causing your problems. If
it's LDAP user, could you try to run ldbsearch -H
/var/lib/sss/db/cache_<sssd_domain_name>.ldb and paste me the object
representing the user? You can also look if there is a group object with GID
990 just to be sure.
One other idea, try to grep if there is a local group with GID 989, that might
also be the problem. id -G might give you some more information about this as
well.
Thanks
Jan