I've seen this on two different customer systems. Here is what is pinted to the log.winbindd: entry_index = 26, num_entries = 47 could not look up gid for group DocBaseAdmin entry_index = 27, num_entries = 47 could not look up gid for group EH_S_Admin entry_index = 28, num_entries = 47 could not look up gid for group Business entry_index = 29, num_entries = 47 could not look up gid for group Clinical entry_index = 30, num_entries = 47 could not look up gid for group RRC_Admin entry_index = 31, num_entries = 47 could not look up gid for group Cellbio_Admin entry_index = 32, num_entries = 47 could not look up gid for group Clinical_Admin wbinfo -g actually shows these groups: RENOVIS\RRC_Admin RENOVIS\DocBaseAdmin RENOVIS\Business RENOVIS\EH_S_Admin RENOVIS\Cellbio_Admin RENOVIS\Clinical_Admin RENOVIS\Clinical So we are able enumerate the groups, we're just don't have a record of their GID (because we actually have this SID as a user). What I have done in the past to "fix" this problem is to edit the customer's . tdb files with tdbtool so that their groups will be recognized.
If the domain is in a certain state (unknown to me), winbindd can fail to discern whether SIDs are for users or groups, and makes a guess. If it guesses incorrectly, some users/groups will be imported incorrectly into winbindd_idmap.tdb (e.g. setting a User SID with a GID label in the tdb)
This was logged against beta1 and has no real activity in 2 months. Is this still a bug? If there is no more information posted in the next week, I'm going to close it out due to lack of information. (btw....I have no idea what my comment on 8/15 means)
no more comments, no acticity....
originally reported against 3.0.0beta1. CLeaning out non-production release versions.
sorry for the same, cleaning up the database to prevent unecessary reopens of bugs.
database cleanup