Client is WinXP SP1. Profile directory shows up like drwx------+ 2 jerry 2147483404 4096 05-22 14:14 WinXP/ 2.4.20+acl kernel. Samba_3_0 cvs code as of today (2003-05-22)
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 behavior. 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.
database cleanup