[linux-cifs-client] Re: Unable to mount using sec=none and mount.cifs

[Jeff Layton]

On Tue, 11 Mar 2008 16:02:25 +0100
Rasmus Ory Nielsen <ron at ron.dk> wrote:

> Hi,
> 
> I have the same problems with the netapp + plaintext combination.
> If anyone finds a solution please post to this list.
> 
> Best regards,
> Rasmus Ory Nielsen
> 
> 
> Ganael LAPLANCHE skrev:
> > On Thu, 6 Mar 2008 11:10:20 -0500, Christopher DeMarco wrote
> > 
> >>> You also have to remove sec=none which will try to bind you
> >>> as guest (null user).
> >> Indeed it does.  But removing the option changes nothing -- same
> >> error.
> >>
> >> FWIW, when I authenticate "incorrectly" -- bad password -- I see log
> >> messages on the filer.  The old smbfs module, when mounting *without*
> >> sec=none, also spawns a log message on the filer, but the
> >> configuration I'm using now *doesn't generate log messages on the
> >> filer*.
> > 
> > Same thing here, nothing appears on the filer. Are you also working on a filer
> > from Netapp ?
> > 
> > Here are connection captures taken with Wireshark on the client machine (Kubuntu
> > , 2.6.22-14-generic, cifs module v1.50 manually recompiled with
> > CONFIG_CIFS_WEAK_PW_HASH option) trying to connect to a Netapp filer running
> > v7.1 (same error on 7.2) :
> > 
> > 1) Using SMBFS, OK :
> > 
> > Command : smbmount //157.99.64.123/Sis /mnt/tmp -o
> > username=martymac,netbiosname=CIFSCLT,workgroup=WORKGROUP
> > 
> > Capture, see :
> > http://contribs.martymac.com/misc/net-captures/mount.smbfs-20080307.pcap
> > 
> > 2) Using CIFS, error :
> > 
> > Command : mount.cifs //157.99.64.123/Sis /mnt/tmp -o
> > user=martymac,netbiosname=CIFSCLT,domain=WORKGROUP
> > 
> > Capture, see :
> > http://contribs.martymac.com/misc/net-captures/mount.cifs-20080307.pcap
> > 
> > For 2), I use 0x37 as SecurityFlags. Netapp requires clear-text passwords as it
> > authenticates users in a standalone mode, against our LDAP server.
> > 
> > Clear-text password seems to be negociated (as seen in the 'Negociate Protocol
> > Response' part), but connection ends with a 'Server Error' (and a 'Non-specific
> > error code').
> > 

Yes, looks like the server specified plaintext passwords, but then the
client decided to send it LANMAN hashes anyway (which makes me wonder
where it got the encryption key...hmmm). You may want to try a newer
kernel, there have been some fixes in this area in the last several
months.

Alternately, you may want to try a more restrictive setting for
SecurityFlags (maybe 0x20020) to force plaintext passwords and see if
that works around the problem.

Cheers,
-- 
Jeff Layton <jlayton at redhat.com>