attempts to connect to the domain master (samba1) are fine, but connecting to a non-master server (pisa) fails to login - smbclient says "session setup failed: NT_STATUS_LOGON_FAILURE". reverting the non-master to 3.0.24 gets it working again. domain master's [global] smbd.conf section: workgroup = YKCSCI netbios name = samba1 comment = Samba Server 1 server string = godot printing = bsd lpq cache time = 10 print command = /york/pkg/samba/lib/mylp %p %s lpq command = /york/pkg/samba/lib/mylpq %p lprm command = /york/pkg/samba/lib/mylprm %p %j printcap name = /york/pkg/samba/lib/printcap load printers = yes use client driver = yes guest account = nobody log file = /spool/misc/samba/log.%m max log size = 20 short preserve case = yes preserve case = yes lock directory = /spool/misc/samba/locks locking = yes security = user encrypt passwords = yes socket options = TCP_NODELAY interfaces = 144.32.80.7/255.255.254.0 144.32.40.4/255.255.254.0 local master = yes os level = 33 domain master = yes preferred master = yes wins support = yes name resolve order = wins hosts bcast and the non-master's: workgroup = YKCSCI netbios name = PISA server string = WWW/FTP server interfaces = 144.32.40.0/255.255.254.0 127.0.0.1/255.0.0.0 security = SERVER password server = SAMBA1 log level = 1 log file = /var/log/samba/log.%m max log size = 50 lock directory = /var/log/samba/locks name resolve order = hosts bcast preferred master = No local master = No domain master = No
Can you please upload a debug level 10 log of smbd running on pisa? Thanks Volker
Created attachment 2695 [details] output of "smbd -d 10 -i" from affected server pisa is a production server, and i had to revert it to 3.0.24 to keep it working. i've set up an equivalent server (pc004) - which suffers from exactly the problem, so i've attached the log from that. thanks.
To bug reporter: do you use "username map" on the client? There's a very similar bug (which I just reproduced) in Debian: http://bugs.debian.org/424046 The bug doesn't happen with "security=domain". However, "our" bug is definitely related to "username map" and I'm trying to find whether I should report it separately or not.
A similar bug was reported on Debian: http://bugs.debian.org/424610
Please ignore my previous comment. It was intended for #4619
Fixed for 3.0.25a