The Samba-Bugzilla – Bug 109
unitiailized gid when writing a user profile
Last modified: 2005-11-14 09:29:48 UTC
Client is WinXP SP1. Profile directory shows
drwx------+ 2 jerry 2147483404 4096 05-22 14:14 WinXP/
2.4.20+acl kernel. Samba_3_0 cvs code as of today
Looks like the issue from the sid_to_gid code not having a valid mapping.
Particularly the pdb_ldap bugs that we had in this area. Should also be better
with idmap_ldap in (what happened to that?)
I'm told that this should be fixed with idra's new idmap patch.
not fixed. Working on it now.
$ ls -ld test
drwxr-xr-x 2 jerry 2147483404 4096 06-26 10:19 test/
sent to samba-technical....
------ original message ---------------------
I've found the cause of this bug. It is the call to sid_to_gid()
in make_server_info_sam(). Probably appears elsewhere as well.
When using an ldapsam backend, if the sambaPrimaryGroupSID is unmapped,
we'll drop back to the algorithm is generating gids.
We seem to set DOMAIN_GROUP_USERS as the primary group for new
entries in several backends. Do we even really need this attribute?
Shouldn't we be deriving it from the primary UNIX group of the user
and let the group mapping handle things. We can store it in SAM_ACCOUNT
for quickness. That's ok. But actually storing a SID that may not be
mapped to the user's primary UNIX group seems inconsistent with other
Can one of you convince me that we we shouldn't just throw away this
attribute value in the code and just generate the SID from the primary
gid of the user? As it stands now, it is possible (and probable
in default installations) that the group membership Samba is using does
not match the UNIX group membership of the user.
Recent changes have occoured to the symptom of this bug.
You will no longer get an 'uninitialised' GID, you will be allocated a GID out
of the GID pool specified with 'idmap gid'.
I think I have fixed this up, restoring previous behaviour where the user's unix
primary group is used regardless.
However, I'll leave this bug open, as it looks like other work is happening here
that might cause the revertion of these changes.
Oops, I closed it. I think it's safe to say that it's closed anyway.
works fine in latest CVS
originally reported against 3.0.0beta1. CLeaning out
non-production release versions.