There's a new issue if a user belongs to 16 groups. Upon trying to map a drive or browse the network for a server with 3.0.3 the user receives an error: The mapped network drive could not be created because the following error has occurred: The specified network name is no longer available. If I remove the user from one group, the mapping works again. Here's a piece of a debug level 10 log with the appropriate errors: [2004/04/29 08:47:24, 10] lib/system_smbd.c:sys_getgrouplist(118) sys_getgrouplist: user [bvebg7] [2004/04/29 08:47:24, 10] lib/system_smbd.c:sys_getgrouplist(127) sys_getgrouplist(): disabled winbindd for group lookup [user == bvebg7] [2004/04/29 08:47:24, 3] smbd/sec_ctx.c:push_sec_ctx(256) push_sec_ctx(0, 0) : sec_ctx_stack_ndx = 1 [2004/04/29 08:47:24, 3] smbd/uid.c:push_conn_ctx(351) push_conn_ctx(0) : conn_ctx_stack_ndx = 0 [2004/04/29 08:47:24, 3] smbd/sec_ctx.c:set_sec_ctx(288) setting sec ctx (0, 0) - sec_ctx_stack_ndx = 1 [2004/04/29 08:47:24, 5] auth/auth_util.c:debug_nt_user_token(486) NT user token: (NULL) [2004/04/29 08:47:24, 5] auth/auth_util.c:debug_unix_user_token(505) UNIX token of user 0 Primary group is 0 and contains 0 supplementary groups [2004/04/29 08:47:24, 8] lib/util_getent.c:remove_duplicate_gids(330) remove_duplicate_gids: Enter 17 gids [2004/04/29 08:47:24, 8] lib/util_getent.c:remove_duplicate_gids(348) remove_duplicate_gids: Exit 16 gids [2004/04/29 08:47:24, 3] smbd/sec_ctx.c:pop_sec_ctx(386) pop_sec_ctx (0, 0) - sec_ctx_stack_ndx = 0 [2004/04/29 08:47:24, 10] lib/system_smbd.c:sys_getgrouplist(118) sys_getgrouplist: user [bvebg7] [2004/04/29 08:47:24, 10] lib/system_smbd.c:sys_getgrouplist(127) sys_getgrouplist(): disabled winbindd for group lookup [user == bvebg7] [2004/04/29 08:47:24, 3] smbd/sec_ctx.c:push_sec_ctx(256) push_sec_ctx(0, 0) : sec_ctx_stack_ndx = 1 [2004/04/29 08:47:24, 3] smbd/uid.c:push_conn_ctx(351) push_conn_ctx(0) : conn_ctx_stack_ndx = 0 [2004/04/29 08:47:24, 3] smbd/sec_ctx.c:set_sec_ctx(288) setting sec ctx (0, 0) - sec_ctx_stack_ndx = 1 [2004/04/29 08:47:24, 5] auth/auth_util.c:debug_nt_user_token(486) NT user token: (NULL) [2004/04/29 08:47:24, 5] auth/auth_util.c:debug_unix_user_token(505) UNIX token of user 0 Primary group is 0 and contains 0 supplementary groups [2004/04/29 08:47:24, 8] lib/util_getent.c:remove_duplicate_gids(330) remove_duplicate_gids: Enter 17 gids [2004/04/29 08:47:24, 8] lib/util_getent.c:remove_duplicate_gids(348) remove_duplicate_gids: Exit 17 gids [2004/04/29 08:47:24, 3] smbd/sec_ctx.c:pop_sec_ctx(386) pop_sec_ctx (0, 0) - sec_ctx_stack_ndx = 0 [2004/04/29 08:47:24, 0] auth/auth_util.c:get_user_groups(695) get_user_groups: failed to get the unix group list [2004/04/29 08:47:24, 0] lib/fault.c:fault_report(36) =============================================================== [2004/04/29 08:47:24, 0] lib/fault.c:fault_report(37) INTERNAL ERROR: Signal 10 in pid 25427 (3.0.3) Please read the appendix Bugs of the Samba HOWTO collection [2004/04/29 08:47:24, 0] lib/fault.c:fault_report(39) =============================================================== [2004/04/29 08:47:24, 0] lib/util.c:smb_panic2(1398) PANIC: internal error
remove_duplicate_gids: Enter 17 gids remove_duplicate_gids: Exit 17 gids That's 17 (assuming 16 secondary + primary group). What version of Solaris is this ? And signal 10 == SIGUSR1 which is really strange to die on....
Forwarded mail: ---------------- It's running under Solaris 8. What's unusual is that it strips out the duplicate group earlier, but not the second time through. And it's not 16 + primary group. It's 15 +primary group. It's counting the primary group twice and stripping out the duplicate copy. If I have the user in his primary group +14 others, it works. If I have the user in his primary +15, it doesn't.
Created attachment 485 [details] move call to remove_duplicate_gis() to prevent calling it on a bad array of gids
Patch should fix the crash. Works in my tests cases. Thanks for reporting the bug.
Created attachment 488 [details] #2 -- move call to remove_duplicate_gis() to prevent calling it on a bad array of gids
sorry for the same, cleaning up the database to prevent unecessary reopens of bugs.
database cleanup