Hi there, I installed Sernet Samba 4.1.7 and provisoned a new domain. After that I generated some groups and set them as "valid users" in smb.conf. But I can not connect because of that error: [2014/05/08 15:47:05.066209, 3] ../libcli/security/dom_sid.c:208(dom_sid_parse_endp) string_to_sid: SID @mitarbeiter is not in a valid format This is my smb.conf: # Global parameters [global] workgroup = CUSTOMERTEAM realm = CUSTOMERTEAM.LOCAL netbios name = CUSTOMERSRV01 server role = active directory domain controller server services = +dns, +dnsupdate dns forwarder = 8.8.8.8 allow dns updates = nonsecure and secure template shell = /bin/false printcap name = /dev/null load printers = no printing = bsd veto files = /.DS_Store/._.DS_Store/ delete veto files = yes obey pam restrictions = yes pam password change = yes # Debugging log file = /var/log/samba/samba.log max log size = 10000 log level = 3 debug timestamp = yes [netlogon] path = /var/lib/samba/sysvol/customerteam.local/scripts read only = No [sysvol] path = /var/lib/samba/sysvol read only = No [profiles] path = /mnt/data/profile read only = no create mask = 0600 directory mask = 0700 profile acls = yes valid users = %U [homes] comment = Userverzeichnis browseable = no read only = no create mask = 0600 directory mask = 0700 valid users = %U [customerdata] comment = GfP Daten path = /mnt/data/customerdata valid users = @mitarbeiter force group = mitarbeiter browseable = yes writable = yes create mode = 0660 directory mode = 0770 Winbind is working: $ getent group | grep mitarbeiter GFPTEAM\mitarbeiter:*:3000020: $ wbinfo -n mitarbeiter S-1-5-21-2006001837-2318145643-2440792074-1104 SID_DOM_GROUP (2) A similar setup is working perfect, but I can not find an error in the config or elsewhere :-/ Best regards Tom
Please upload a full debug level 10 log of the login attempt. It is unlikely that the error message you quote is the primary reason for the problem. Thanks, Volker
Created attachment 9930 [details] Samba Log with Debuglevel 10 Here is the debug Log
[2014/05/09 09:07:00.289735, 5, pid=27815, effective(0, 0), real(0, 0)] ../source3/smbd/share_access.c:127(token_contains_name) mitarbeiter is a None, expected a group It seems group "mitarbeiter" does not exist. Are sure you have that as a group?
Yes, I'm sure: root@customersrv01:~# wbinfo -n mitarbeiter S-1-5-21-2006001837-2318145643-2440792074-1104 SID_DOM_GROUP (2) root@customersrv01:~# getent group | grep mitarbeiter CUSTOMERTEAM\mitarbeiter:*:3000020:
And: root@customersrv01:~# id administrator uid=0(root) gid=100(users) Gruppen=0(root),100(users),3000004(CUSTOMERTEAM\Group Policy Creator Owners),3000006(CUSTOMERTEAM\Enterprise Admins),3000008(CUSTOMERTEAM\Domain Admins),3000007(CUSTOMERTEAM\Schema Admins),3000020(CUSTOMERTEAM\mitarbeiter),3000023(CUSTOMERTEAM\scannerfms),3000021(CUSTOMERTEAM\finance),3000022(CUSTOMERTEAM\scanner),3000028(CUSTOMERTEAM\crmdb),3000019(CUSTOMERTEAM\ceo) root@customersrv01:~# kinit administrator Password for administrator@CUSTOMERTEAM.LOCAL: Warning: Your password will expire in 998 days on Tue Jan 31 14:32:05 2017
Ok, thanks. This might be a problem specific to the AD DC setup that you are using. While we would wish that this works seamlessly already, we are still working on the integration issues. Would it be an option for you to split off the customerdata share to a different fileserver? You could use msdfs proxy to make this completely transparent for the clients.
This setup is not really specific: - samba-tool domain provision - Created Group "mitarbeiter" - Added this Group to Administrator - Created smb.conf and Share - restarted samba
I'm not saying that this is specific, I'm just saying that we have integration issues that might show up like this. This area undergoes significant re-architecture right now, and I'm not sure we will backport this work to 4.1.x. So if you can wait for a few months, it's okay, this will eventually get fixed. But don't hold your breath for it. I can just offer the alternative approach: Set up a member file server with winbind. That should work. If it does not, we will promptly fix the problem.
Ok, thanks for your response. We will think about that, but for now it is ok (and documented for other).
I had the same problem, which was solved by the patch from bug 9570.
*** This bug has been marked as a duplicate of bug 9570 ***