samba - Sep 2006 - samba breaks during user authentication after it was updated

Hello,
I am running samba on a machine running fedora 5. I did not know the system
was configured to automatically update the system via cron, and when it put
the new samba on last night, seems to have broken things. It is coredumping
now whenever a user tries to authenticate. 

Our system is set up with user level security which i manage via smbpasswd
so there are no windows domains involved. The machine has been sitting
nicely on a subnet with a w2k active directory domain controller which is
used for something entirely different altogether. The problem started
happening right after the yum update last night. 

Here is the update messege from /var/log/messages: 

Sep 27 04:19:50 server yum: Updated: samba-common.i386 3.0.23c-1.fc5
Sep 27 04:19:53 server yum: Updated: guile.i386 5:1.6.7-7.fc5
Sep 27 04:19:55 server yum: Updated: samba-client.i386 3.0.23c-1.fc5
Sep 27 04:20:01 server yum: Updated: samba.i386 3.0.23c-1.fc5


And here is what happens when a user maps their share and gets prompted for
a username/password on their xp client: 


Sep 27 09:42:30 server smbd[16675]:
=============================================================== 
Sep 27 09:42:30 server smbd[16675]: [2006/09/27 09:42:30, 0]
lib/fault.c:fault_report(42) 
Sep 27 09:42:30 server smbd[16675]:   INTERNAL ERROR: Signal 11 in pid 16675
(3.0.23c-1.fc5) 
Sep 27 09:42:30 server smbd[16675]:   Please read the Trouble-Shooting
section of the Samba3-HOWTO 
Sep 27 09:42:30 server smbd[16675]: [2006/09/27 09:42:30, 0]
lib/fault.c:fault_report(44) 
Sep 27 09:42:30 server smbd[16675]:    
Sep 27 09:42:30 server smbd[16675]:   From:
http://www.samba.org/samba/docs/Samba3-HOWTO.pdf 
Sep 27 09:42:30 server smbd[16675]: [2006/09/27 09:42:30, 0]
lib/fault.c:fault_report(45) 
Sep 27 09:42:30 server smbd[16675]:
=============================================================== 
Sep 27 09:42:30 server smbd[16675]: [2006/09/27 09:42:30, 0]
lib/util.c:smb_panic(1614) 
Sep 27 09:42:30 server smbd[16675]:   PANIC (pid 16675): internal error 
Sep 27 09:42:30 server smbd[16675]: [2006/09/27 09:42:30, 0]
lib/util.c:log_stack_trace(1721) 
Sep 27 09:42:30 server smbd[16675]:   BACKTRACE: 20 stack frames: 
Sep 27 09:42:30 server smbd[16675]:    #0 smbd(log_stack_trace+0x2d)
[0x7c18ad] 
Sep 27 09:42:30 server smbd[16675]:    #1 smbd(smb_panic+0x5d) [0x7c19dd] 
Sep 27 09:42:30 server smbd[16675]:    #2 smbd [0x7ad51a] 
Sep 27 09:42:30 server smbd[16675]:    #3 [0x239420] 
Sep 27 09:42:30 server smbd[16675]:    #4 /lib/libc.so.6(__strdup+0x1f)
[0x9f3893] 
Sep 27 09:42:30 server smbd[16675]:    #5 /lib/libnsl.so.1(nis_list+0x5d2)
[0xca4b5f] 
Sep 27 09:42:30 server smbd[16675]:    #6
/lib/libnss_nisplus.so.2(_nss_nisplus_setnetgrent+0x8f) [0x45a62e] 
Sep 27 09:42:30 server smbd[16675]:    #7 /lib/libc.so.6(innetgr+0xb2)
[0xa6ed05] 
Sep 27 09:42:30 server smbd[16675]:    #8 smbd(user_in_netgroup+0x65)
[0x5f81e5] 
Sep 27 09:42:30 server smbd[16675]:    #9
smbd(token_contains_name_in_list+0x23d) [0x5fabdd] 
Sep 27 09:42:30 server smbd[16675]:    #10
smbd(is_share_read_only_for_token+0x98) [0x5faed8] 
Sep 27 09:42:30 server smbd[16675]:    #11 smbd(change_to_user+0x442)
[0x6395b2] 
Sep 27 09:42:30 server smbd[16675]:    #12 smbd [0x658b38] 
Sep 27 09:42:30 server smbd[16675]:    #13 smbd(make_connection+0x194)
[0x659fa4] 
Sep 27 09:42:30 server smbd[16675]:    #14 smbd(reply_tcon_and_X+0x21d)
[0x61d8ed] 
Sep 27 09:42:30 server smbd[16675]:    #15 smbd [0x6550e0] 
Sep 27 09:42:30 server smbd[16675]:    #16 smbd(smbd_process+0x7ab)
[0x65621b] 
Sep 27 09:42:30 server smbd[16675]:    #17 smbd(main+0xbd0) [0x86ff90] 
Sep 27 09:42:30 server smbd[16675]:    #18
/lib/libc.so.6(__libc_start_main+0xdc) [0x99f4e4] 
Sep 27 09:42:30 server smbd[16675]:    #19 smbd [0x5e0701] 
Sep 27 09:42:30 server smbd[16675]: [2006/09/27 09:42:30, 0]
lib/fault.c:dump_core(173) 
Sep 27 09:42:30 server smbd[16675]:   dumping core in
/var/log/samba/cores/smbd 
 

Smbclient gives me the following: 

# Smbclient //localhost/Myshare -U username
Password: 
tree connect failed: Call returned zero bytes (EOF)
 
My workaround has been to set things to share level security with no user
authentication until i can either fix this problem or install a different
version of samba and get my existing smb.conf working. Not sure if/how I can
roll it back so if that's an option then great. 

This could have been avoided had i better inspected this system before
managing it!!

Thanks for any help/advice,
Harry

Harry Doyle <harry <at> locals.ca> writes:
> 
> Hello,
> I am running samba on a machine running fedora 5. I did not know the system
> was configured to automatically update the system via cron, and when it put
> the new samba on last night, seems to have broken things. It is coredumping
> now whenever a user tries to authenticate. 
> 
> Our system is set up with user level security which i manage via smbpasswd
> so there are no windows domains involved. The machine has been sitting
> nicely on a subnet with a w2k active directory domain controller which is
> used for something entirely different altogether. The problem started
> happening right after the yum update last night. 
> 
[snipped]
> Sep 27 09:42:30 server smbd[16675]:    #5 /lib/libnsl.so.1(nis_list+0x5d2)
> [0xca4b5f] 
> Sep 27 09:42:30 server smbd[16675]:    #6
> /lib/libnss_nisplus.so.2(_nss_nisplus_setnetgrent+0x8f) [0x45a62e] 
> Sep 27 09:42:30 server smbd[16675]:    #7 /lib/libc.so.6(innetgr+0xb2)
> [0xa6ed05] 
> Sep 27 09:42:30 server smbd[16675]:    #8 smbd(user_in_netgroup+0x65)
> [0x5f81e5] 
Looks like an error in libnss in the netgroup code...
> Smbclient gives me the following: 
> 
> # Smbclient //localhost/Myshare -U username
> Password: 
> tree connect failed: Call returned zero bytes (EOF)
Exactly the error we were seeing
> My workaround has been to set things to share level security with no user
> authentication until i can either fix this problem or install a different
> version of samba and get my existing smb.conf working. Not sure if/how I
can
> roll it back so if that's an option then great. 
Ouch, but it works!
> This could have been avoided had i better inspected this system before
> managing it!!
> 
> Thanks for any help/advice,
> Harry
> 

Not sure what your configuration is, but in the /etc/nsswitch.conf file we had:

hosts:      files dns
netgroup:   nisplus

Since we are not using NIS, nisplus, nor netgroups, I commented out the line:

#netgroup:   nisplus

Once I did that I restarted Samba, and now things work again!

Hope this helps,  John