smbclient no longer works with null passwords. Null passwords work fine for the 2.2.8a client, so the server is not the issue. I traced the packets on the two smbclients, and I see several differences. The command I ran was: smbclient //g4-box-1/dood -I 192.168.5.90 -U dood I used the same command on both 2.2.8a and 3.0 systems. Here are the differences I saw in the packets: 1. client sends "Extended Security Negotiation: Extended security negotiation is supported" on 3.0, but not on 2.2.8a 2. 2.2.8a client sends ANSI Password, Unicode Password, and uppercased-account name. Meanwhile, 3.0 client doesn't send either passwords, and sends a lowercased-account name. I think this is actually the key here. 3. the "primary domain" sent by 2.2.8a is the client's default domain, while the "primary domain" sent by 3.0 is the domain of the share being accessed 4. 2.2.8a sends "SMB Command: Session Setup AndX (0x73)" and gets response "NT Status: STATUS_SUCCESS (0x00000000)" 3.0 sends same command and gets response "NT Status: STATUS_LOGON_FAILURE (0xc000006d)" The server's smb.conf file includes the following three lines: security = user encrypt passwords = yes null passwords = yes If I change the 'encrypt passwords' to '= no', smbclient-3.0 works fine. The problem is that I have the exact same problem on hosts over which I have no control of the smb.conf file, for example Mac OS X 10.3. 10.3 appears to have the same behavior as my linux samba host with the above three lines in the smb.conf. When I analyze the packets sent between the client and the server, I see the following difference in the frames (see attatchments for full frame decode): samba-2.2.8a sending encrypted null password: < Byte Count (BCC): 69 < ANSI Password: 4C0154EFEF076CCBAE3A6256E351DF5A... < Unicode Password: B30B73818904C5A7111948521702F985... < Account: DOOD < Primary Domain: ABCD samba-3.0 sending no password: > Byte Count (BCC): 26 > Account: dood > Primary Domain: WORKGROUP Note that the primary domain is also different: 3.0 uses the default domain WORKGROUP, while 2.2.8a uses the default domain of the client ("ABCD").
This has nothing to do with libsmbclient ...
current behavior is by design.
Well then I guess I'm out of luck with v3.x. I'll have to stick to using 2.2.8a. May I ask what was the design goal that conflicts with the feature of having NULL passwords? Why is that goal important for v3 and not v2.2.8a?