This is my smb.conf: [global] security = ADS workgroup = CEMS realm = CEMS.UWE.AC.UK netbios name = STORAGE local master = no server signing = auto client use spnego = yes clustering = yes idmap backend = nss idmap uid = 1000-1000000 idmap gid = 1000-1000000 winbind use default domain = Yes winbind trusted domains only = Yes Installed Samba 3.3.6 with cluster support. Got CTDB 1.0.86 up and running and CTDB starts nmbd, smbd and most importantly winbind with no problems. Added a node to a domain and can now run "net ads testjoin" on all nodes and I get "Join is OK". Can also run "smbclient -U domainuser -L localhost" on all nodes and I get a listing of available shares. I can run "wbinfo -u" and I get all the users I expected, also I can run "wbinfo -g" and I get all the groups I expected. Running "wbinfo -n cemsstaff" provides me with: "S-1-5-21-1957994488-1500820517-839522115-11335 Domain Group (2)" this is what I was expecting. While running "wbinfo -s S-1-5-21-1957994488-1500820517-839522115-11335" gives me: "CEMS\cemsstaff 2" which looks pretty good. I check nss switch with "getent group cemsstaff" and this gives me: "cemsstaff:*:1040:domainuser1,domainuser2" expect of course with loads of usernames that exist on my domain. So nss switch is working fine. Here is where I have a problem: I run "wbinfo -G 1040" but I get: "Could not convert gid 1040 to sid" According to nss switch GID 1040 is "cemsstaff" which from a previous test (wbinfo -n cemsstaf) I know translates with no problems to a SID. At this point I have collected some log level 10 log files, please attached. So next I try "wbinfo -Y S-1-5-21-1957994488-1500820517-839522115-11335" and it correctly gives me: 1040 So I run "wbinfo -G 1040" again and this time it works and give me the above SID. So I run "net cache flush" and then "wbinfo -G 1040" but it fails again with: Could not convert gid 1040 to sid Exactly the same symptons when work with UIDs. In summary winbind correctly resolves: name ->SID (wbinfo -n) SID-> name (wbinfo -s) SID->UID (wbinfo -S) SID->GID (wbinfo -Y) But doesn't work (unless cached from other working commands) with: UID->SID (wbinfo -U), GID->UID (wbinfo -G)
Created attachment 4504 [details] log-wb-CEMS (CEMS is my domain) Log File extract for failed "wbinfo -G 1040"
Created attachment 4505 [details] log-wbinfo Log File extract for failed "wbinfo -G 1040"
Created attachment 4506 [details] log-winbindd Log File extract for failed "wbinfo -G 1040"
Created attachment 4507 [details] log-winbindd-idmap Log File extract for failed "wbinfo -G 1040"
(In reply to comment #0) When I said: > Exactly the same symptons when work with UIDs. I meant to say: Exactly the same symptoms when using UIDs instead of GIDs.
I think the thing that is the most interesting is that the GID I was looking for was 1040 and "getent group 1040" says its called "cemsstaff", which it is. So when I run "net flush cache && wbinfo -G 1040", if you look at the log.winbindd, you find a entry: [2009/08/03 20:23:50, 10] winbindd/winbindd.c:process_request(403) process_request: request fn LOOKUPNAME [2009/08/03 20:23:50, 3] winbindd/winbindd_sid.c:winbindd_lookupname(102) [11582]: lookupname *\cemsstaff So it looks like it translates GID 1040 to cemsstaff!! Yet its not returning the SID. Again if I do a "wbinfo -n cemsstaff" it returns the SID and if I then "wbinfo Y SID" it returns the GID 1040. At that point its cached so "wbinfo -G 1040" it returns the right SID but if I just flush the cache it won't work using "wbinfo -G 1040".
Great News! I got it to work, but with the following config. Tomorrow I will figure out what elements in the config work and what don't. [global] # Windows Domain Information security = ADS workgroup = CEMS realm = CEMS.UWE.AC.UK netbios name = STORAGE local master = no passdb backend = smbpasswd clustering = yes idmap backend = tdb2 groupdb config : backend = tdb idmap uid = 1000000-1999999 idmap gid = 1000000-1999999 idmap config CEMS : backend = nss idmap config CEMS : range = 1000-999999 winbind nested groups = Yes winbind use default domain = Yes
Hi John, As discussed on IRC : The last config looks good. We will see if there are remaining issues. Maybe e can close the bug as NOT_A_BUG. Cheers - Michael
Cheers Michael, I will keep trying diffrent settings to confirm what the exact solution was that fixed this issue. Unforutetly I see have a another issue with my config, raised it as a new bug as the symptons have changed, if you get time please check it out: https://bugzilla.samba.org/show_bug.cgi?id=6609 Thanks, overfuse (John Simmonds) (In reply to comment #8) > Hi John, > > As discussed on IRC : The last config looks good. > We will see if there are remaining issues. > Maybe e can close the bug as NOT_A_BUG. > > Cheers - Michael >
I am certain now that its because you always need a writable backend for possible allocation. With just the read-only nss backend it fails. Is it a bug or is it not meant to work with just a read-only backend, i.e. nss in this case?
nss is not suitable as a default backend. the problem was an invalid configuration.