Red Hat Bugzilla – Bug 104162
smbclient does not work
Last modified: 2014-08-31 19:25:21 EDT
Description of problem:
I can no longer use smbclient to connect to a share.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. I have [homes] shared.
2. smbclient //share/name -U user
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]
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.