Description of problem: I can no longer use smbclient to connect to a share. Version-Release number of selected component (if applicable): samba-3.0.0-5rc1 How reproducible: 100% Steps to Reproduce: 1. I have [homes] shared. 2. smbclient //share/name -U user [enter password[ 3. Get 'tree connect failed: SUCCESS - 0' Using nautilus 'smb://share/name' works fine. Note: This prevents redhat-config-printer from working.
WORKSFORME, using the 3.0.0-5rc1 smbclient talking to a samba-2.2.7-3.21as (ia64) server. Can you attach your smb.conf files from both the client and the server systems?
Created attachment 94392 [details] smb.conf This is the smb.conf from the server. I run smbclient on the same machine, so the smb.conf for the client is the same; or else I see the same result from a freshly installed Cambridge machine as the client.
I see you are using share level security. The documentation states: "Please note that there are reports that recent MS Windows clients do not like to work with share mode security servers. You are strongly discouraged from using share level security." Can you reproduce the problem when using user level security? If you need to provide unathenticated access to your printers, look at setting the "guest ok" paramater for those shares.
Changing from share- to user-level security has made the problem go away. [Note, though, that there is no Windows machine in the loop. Just one Linux machine on its own, with SMB over local loopback.]
The other thing I've noticed is that you're prohibiting plaintext and lanman authentication by the client (smbclient). This may not mix well with the old share level security. If you must use share level security, try commenting out the "client lanman auth = No" and "client plaintext auth = No" lines. I've also sent a msg about this upstream.
Changing these values using SWAT doesn't seem to make them stick -- they are both 'No' in the web interface even when the lines are absent from smb.conf. (And in this situation, with share-level security, the problem is still present.)
Fixed in Samba 3.0 RC4 (just released). 'client ntlmv2 auth' overrides 'client lanman auth'. We changed 'client ntlmv2 auth' to default to 'no' again.
This is fixed in current Samba rpms.