[Samba] Domain users are loosing there groups after some time.

Benedikt Schindler BeniSchindler at gmx.de
Thu Mar 15 04:51:32 MDT 2012


Hello,

i just did a workaround. Most of our files and most of our employees
have a permission for the group "Domain\Employees". So we changed in
windows the primary group of each user to "Domain\Employee". The primary
group did not get lost in samba 3.6.3.

(If you edit the groups of a user in windows, there is a button "Set
primary group".)

This did not solve the problem, but it reduced the problem for us to a
working minimum.


Which samba version did you have before the update?
Because i don't know which version we had before our update, so i
couldnt't define where the bug went into the code.

Best regards,
Benedikt Schindler




Golostenov Mikhail wrote:

> Hello.
>
> You write in mailing.unix.samba about problem with loosing groups in
> samba 3.6.3
> I have update my samba servers to this version and have same problem.
> How did you decide this problem?
>
> Thanks.
>
> Best regards,
>
> Golostenov Mikhail
> System Administrator
> XSTREAM Company
> Tel./Fax. +7 (495) 984-0266/797-8070 доб. 108
> Skype: xstream-company
> Web: www.xstream.ru
>






Am 03.03.2012 16:36, schrieb Benedikt Schindler:
> Am 02.03.2012 19:59, schrieb Dale Schroeder:
>> On 03/02/2012 5:39 AM, Benedikt Schindler wrote:
>>> Samba version : 3.6.3
>>> Filesystem :    BTRFS
>>> Clients :       XP, Win7
>>> Log Level :     5
>>>
>>>
>>> When we start our samba server everything works fine.
>>> After a few days, some of our users are not allowed to connect to shares
>>> anymore. When we restart the clients they can connect for a short time
>>> and then say have the same problem again.
>>>
>>> When we restart the server everything works fine for a few days again.
>>> We set the "winbind offline logon = yes" and it slowed down the process,
>>> but didn't stop it.
>>>
>>> After a long search i think i found the problem.
>>>
>>> The user has "401217" as mapped ID,
>>> and should be in the groups
>>>    400513
>>>    401612
>>>    401609
>>>    401611
>>>
>>> But samba just put him into
>>>    400513
>>>    401612
>>>    401611
>>>
>>> So samba lost one group. And thats the reason the user is not allowed to
>>> connect to the share, because only the group 401609 has a read permisson.
>>>
>>> Any ideas how that could happen?
>>>
>>>
>>> Here is a log of a "failed" login:
>>>
>>>
>>> [2012/03/02 11:37:52.842978,  5]
>>> ../libcli/security/security_token.c:63(security_token_debug)
>>>    Security token SIDs (15):
>>>      SID[  0]: S-1-5-21-1004336348-920026266-682003330-1217
>>>      SID[  1]: S-1-5-21-1004336348-920026266-682003330-513
>>>      SID[  2]: S-1-5-21-1004336348-920026266-682003330-1612
>>>      SID[  3]: S-1-5-21-1004336348-920026266-682003330-1609
>>>      SID[  4]: S-1-5-21-1004336348-920026266-682003330-1611
>>>      SID[  5]: S-1-1-0
>>>      SID[  6]: S-1-5-2
>>>      SID[  7]: S-1-5-11
>>>      SID[  8]: S-1-22-1-401217
>>>      SID[  9]: S-1-22-2-400513
>>>      SID[ 10]: S-1-22-2-401612
>>>      SID[ 11]: S-1-22-2-401611
>>>      SID[ 12]: S-1-22-2-70000
>>>      SID[ 13]: S-1-22-2-70002
>>>      SID[ 14]: S-1-22-2-70011
>>>     Privileges (0x               0):
>>>     Rights (0x               0):
>>> [2012/03/02 11:37:52.843247,  5]
>>> auth/token_util.c:527(debug_unix_user_token)
>>>    UNIX token of user 401217
>>>    Primary group is 400513 and contains 6 supplementary groups
>>>    Group[  0]: 400513
>>>    Group[  1]: 401612
>>>    Group[  2]: 401611
>>>    Group[  3]: 70000
>>>    Group[  4]: 70002
>>>    Group[  5]: 70011
>>> [2012/03/02 11:37:52.843372,  5] smbd/uid.c:317(change_to_user_internal)
>>>    Impersonated user: uid=(0,401217), gid=(0,400513)
>>> [2012/03/02 11:37:52.843408,  4] smbd/vfs.c:780(vfs_ChDir)
>>>    vfs_ChDir to /home/data
>>> [2012/03/02 11:37:52.843443,  4] smbd/vfs.c:780(vfs_ChDir)
>>>    vfs_ChDir to /home/data
>>> [2012/03/02 11:37:52.843476,  3] smbd/service.c:190(set_current_service)
>>>    chdir (/home/data) failed, reason: Keine Berechtigung
>>> [2012/03/02 11:37:52.843509,  3] smbd/error.c:81(error_packet_set)
>>>    error packet at smbd/process.c(1558) cmd=50 (SMBtrans2)
>>> NT_STATUS_ACCESS_DENIED
>>>
>>>
>>>
>>>
>>> Configuration parts that are maybe interresting:
>>> smb.conf:
>>>
>>>
>>> security = ADS
>>>
>>> socket options = SO_KEEPALIVE IPTOS_LOWDELAY TCP_NODELAY
>>> nt acl support = yes
>>> vfs objects = acl_xattr
>>>
>>> winbind enum users = yes
>>>          winbind enum groups = yes
>>>          winbind offline logon = yes
>>>          allow trusted domains = yes
>>>
>>>          idmap config * : backend     = rid
>>>          idmap config * : range       = 70000-99999
>>>          idmap config * : base_rid    = 0
>>>
>>>          idmap config A : backend     = rid
>>>          idmap config A : range       = 400000-499999
>>>          idmap config A : base_rid    = 0
>>>
>>>          idmap config B : backend  = rid
>>>          idmap config B : range    = 300000-399999
>>>          idmap config B : base_rid = 0
>>
>> Benedikt,
>>
>> Check this bug - https://bugzilla.samba.org/show_bug.cgi?id=8676 - to
>> see if any of these symptoms match those of your systems when the group
>> loss happens.
>>
>> Dale
>>
>>
> 
> 
> Hello Dale,
> 
> none of these symptoms exists on our server.
> 
> And it's more like the existing connection is loosing the group.
> 
> The windows client is connected to "\\server.domain.tld\data" and this
> connection broke after some time. (Because of the group)
> You could open a second connection from the same computer to the same
> server by using "\\server\data" with no problems. And it's not about
> FQDN or not. It also appears the other way arround.
> 
> If you restart the client, the client could connect without any problems
> ... until it looses the group again.
> 
> best regards
> Benedikt
> 



More information about the samba mailing list