Bug 104162 - smbclient does not work
smbclient does not work
Product: Red Hat Raw Hide
Classification: Retired
Component: samba (Show other bugs)
All Linux
medium Severity high
: ---
: ---
Assigned To: Jay Fenlason
David Lawrence
Depends On:
Blocks: CambridgeTarget
  Show dependency treegraph
Reported: 2003-09-10 12:58 EDT by Tim Waugh
Modified: 2014-08-31 19:25 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2004-11-18 15:51:00 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
smb.conf (1.12 KB, text/plain)
2003-09-10 18:12 EDT, Tim Waugh
no flags Details

  None (edit)
Description Tim Waugh 2003-09-10 12:58:00 EDT
Description of problem:
I can no longer use smbclient to connect to a share.

Version-Release number of selected component (if applicable):

How reproducible:

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.
Comment 1 Jay Fenlason 2003-09-10 14:28:50 EDT
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? 
Comment 2 Tim Waugh 2003-09-10 18:12:58 EDT
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.
Comment 3 Jay Fenlason 2003-09-11 10:20:00 EDT
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. 
Comment 4 Tim Waugh 2003-09-11 10:33:04 EDT
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.]
Comment 5 Jay Fenlason 2003-09-11 10:55:14 EDT
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. 
Comment 6 Tim Waugh 2003-09-11 11:05:53 EDT
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.)
Comment 7 Andrew Bartlett 2003-09-13 08:12:29 EDT
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.

Comment 8 Jay Fenlason 2004-11-18 15:51:00 EST
This is fixed in current Samba rpms. 

Note You need to log in before you can comment on or make changes to this bug.