Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.

Bug 104162

Summary: smbclient does not work
Product: [Retired] Red Hat Raw Hide Reporter: Tim Waugh <twaugh>
Component: sambaAssignee: Jay Fenlason <fenlason>
Status: CLOSED CURRENTRELEASE QA Contact: David Lawrence <dkl>
Severity: high Docs Contact:
Priority: medium    
Version: 1.0CC: abartlet, jfeeney, k.georgiou
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2004-11-18 20:51:00 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 100644    
Attachments:
Description Flags
smb.conf none

Description Tim Waugh 2003-09-10 16:58:00 UTC
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.

Comment 1 Jay Fenlason 2003-09-10 18:28:50 UTC
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 22:12:58 UTC
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.

Comment 3 Jay Fenlason 2003-09-11 14:20:00 UTC
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 14:33:04 UTC
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 14:55:14 UTC
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 15:05:53 UTC
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 12:12:29 UTC
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 20:51:00 UTC
This is fixed in current Samba rpms.