using force group = ccdb paramater. Call appears to fail because ccdb is both a user and a group. Relavent log at debug level = 10 [2008/08/16 14:15:05, 5] smbd/uid.c:change_to_root_user(287) change_to_root_user: now uid=(0,0) gid=(0,0) [2008/08/16 14:15:05, 4] smbd/reply.c:reply_tcon_and_X(653) Client requested device type [?????] for share [NETWORK] [2008/08/16 14:15:05, 5] smbd/service.c:make_connection(1376) making a connection to 'normal' service network [2008/08/16 14:15:05, 5] lib/username.c:Get_Pwnam_alloc(133) Finding user guest [2008/08/16 14:15:05, 5] lib/username.c:Get_Pwnam_internals(77) Trying _Get_Pwnam(), username as lowercase is guest [2008/08/16 14:15:05, 5] lib/username.c:Get_Pwnam_internals(110) Get_Pwnam_internals did find user [guest]! [2008/08/16 14:15:05, 10] passdb/lookup_sid.c:lookup_name(69) lookup_name: CCSERVER\ccdb => CCSERVER (domain), ccdb (name) [2008/08/16 14:15:05, 10] passdb/lookup_sid.c:lookup_name(70) lookup_name: flags = 0x077 [2008/08/16 14:15:05, 3] smbd/sec_ctx.c:push_sec_ctx(224) push_sec_ctx(0, 0) : sec_ctx_stack_ndx = 1 [2008/08/16 14:15:05, 3] smbd/uid.c:push_conn_ctx(357) push_conn_ctx(0) : conn_ctx_stack_ndx = 0 [2008/08/16 14:15:05, 3] smbd/sec_ctx.c:set_sec_ctx(324) setting sec ctx (0, 0) - sec_ctx_stack_ndx = 1 [2008/08/16 14:15:05, 5] auth/token_util.c:debug_nt_user_token(464) NT user token: (NULL) [2008/08/16 14:15:05, 5] auth/token_util.c:debug_unix_user_token(490) UNIX token of user 0 Primary group is 0 and contains 0 supplementary groups [2008/08/16 14:15:05, 3] smbd/sec_ctx.c:pop_sec_ctx(432) pop_sec_ctx (0, 0) - sec_ctx_stack_ndx = 0 [2008/08/16 14:15:05, 10] passdb/lookup_sid.c:lookup_name(69) lookup_name: Unix Group\ccdb => Unix Group (domain), ccdb (name) [2008/08/16 14:15:05, 10] passdb/lookup_sid.c:lookup_name(70) lookup_name: flags = 0x077 [2008/08/16 14:15:05, 10] smbd/service.c:find_forced_group(606) ccdb is a User, not a group [2008/08/16 14:15:05, 3] smbd/error.c:error_packet_set(61) error packet at smbd/reply.c(662) cmd=117 (SMBtconX) NT_STATUS_NO_SUCH_GROUP [2008/08/16 14:15:05, 5] lib/util.c:show_msg(645) [2008/08/16 14:15:05, 5] lib/util.c:show_msg(655)
This is strange. It's definately looking for a Unix group, see the line : lookup_name: Unix Group\ccdb => Unix Group (domain), ccdb is winbindd running ? Looks to me like the only way this can happen is by the call to winbind_lookup_name() here : 103 if ((domain[0] != '\0') && 104 (flags & ~(LOOKUP_NAME_DOMAIN|LOOKUP_NAME_ISOLATED)) && 105 (winbind_lookup_name(domain, name, &sid, &type))) { 106 goto ok; 107 } If you explicitly qualify the name in smb.conf with "Unix Group\ccdb" does this fix the problem ? Jeremy.
Ok, without winbindd running I can't reproduce your problem on my local box here. I get (for a share with "force group = +jeremy" and logging in with user jeremy: user_ok_token: share tmp is ok for unix user jeremy [2008/08/16 13:50:15, 5] lib/username.c:Get_Pwnam_alloc(133) Finding user jeremy [2008/08/16 13:50:15, 5] lib/username.c:Get_Pwnam_internals(77) Trying _Get_Pwnam(), username as lowercase is jeremy [2008/08/16 13:50:15, 5] lib/username.c:Get_Pwnam_internals(110) Get_Pwnam_internals did find user [jeremy]! [2008/08/16 13:50:15, 10] passdb/lookup_sid.c:lookup_name(69) lookup_name: JEREMY2\jeremy => JEREMY2 (domain), jeremy (name) [2008/08/16 13:50:15, 10] passdb/lookup_sid.c:lookup_name(70) lookup_name: flags = 0x077 [2008/08/16 13:50:15, 3] smbd/sec_ctx.c:push_sec_ctx(224) push_sec_ctx(0, 0) : sec_ctx_stack_ndx = 1 [2008/08/16 13:50:15, 3] smbd/uid.c:push_conn_ctx(357) push_conn_ctx(0) : conn_ctx_stack_ndx = 0 [2008/08/16 13:50:15, 3] smbd/sec_ctx.c:set_sec_ctx(324) setting sec ctx (0, 0) - sec_ctx_stack_ndx = 1 [2008/08/16 13:50:15, 5] auth/token_util.c:debug_nt_user_token(464) NT user token: (NULL) [2008/08/16 13:50:15, 5] auth/token_util.c:debug_unix_user_token(490) UNIX token of user 0 Primary group is 0 and contains 0 supplementary groups [2008/08/16 13:50:15, 3] smbd/sec_ctx.c:pop_sec_ctx(432) pop_sec_ctx (0, 0) - sec_ctx_stack_ndx = 0 [2008/08/16 13:50:15, 10] passdb/lookup_sid.c:lookup_name(69) lookup_name: Unix Group\jeremy => Unix Group (domain), jeremy (name) [2008/08/16 13:50:15, 10] passdb/lookup_sid.c:lookup_name(70) lookup_name: flags = 0x077 [2008/08/16 13:50:15, 10] passdb/lookup_sid.c:sid_to_gid(1413) sid S-1-22-2-1000 -> gid 1000
Ok, with winbindd running I can reproduce this. Give me a few hours to fix this. Jeremy.
Created attachment 3485 [details] Patch Ok, the fix is attached. The problem was when smbd was asking for a winbindd name to SID lookup of "Unix Group\name" where "name" was also a valid username, the winbindd passdb lookup of that name was losing the domain string info before calling lookup name (ie. lookup_name() was being called with just the string "name", not the full string "Unix Group\name"). The passdb backend of winbindd has to cope with not only names from it's own global SAM domain, but it does lookups for BUILTIN and "Unix User" and "Unix Group" also, so making it guess by losing the domain string is "A Bad Idea" (tm) :-). Note that as winbind globally calls winbind_off() at startup, it's safe for winbind to call sys_getgrnam() to do the "Unix Group" lookup from inside lookup_name().
Thanks so much Jeremy. Would you like me to test it, or wait until 3.2.2? Again, thanks for the speedy work. By the way, I tested in 3.0.31 and 3.0.28a and the problem appeared there also. That said, I see you saying there's a difference with/without winbindd running. What is the preferred role for winbindd, is there ever a time when it's good not to run it? Let me know or if there's a faq or good reading on it. Thanks, Devin Nate
Well more testing is always good :-). The patch works for me but I'd also like to hear if it works for you. I'll look into adding it to the 3.0.x codebase (now in maintanence mode). Cheers, Jeremy.
The patch worked for me also against a clean 3.2.1. (which is what we use). Thanks! Devin Nate
Closing out bug report. Thanks for reporting!