[ 6924.132239] /build/buildd/linux-2.6.28/fs/cifs/cifssmb.c: Dialect: 2 [ 6924.132246] /build/buildd/linux-2.6.28/fs/cifs/cifssmb.c: negprot rc -5 [ 6924.132255] /build/buildd/linux-2.6.28/fs/cifs/connect.c: CIFS VFS: leaving cifs_mount (xid = 3402) rc = -5 [ 6924.132260] CIFS VFS: cifs_mount failed w/return code = -5 With the same setup I managed to mount a Win2003 and samba 3 shares with kerberos. Using smbclient -k or gvfs2 smb:// is ok with the Netapp share. I'm not root, mount.cifs have a correct suid. The /etc/request-key.conf is ok (and it's working with win2003 and samba 3) The machine account in the AD is the same as the reverse dns name. It's working fine with NTLM authentication. As discuss on the list it's look like an Ontap bug, the network dump show : Flags2 : - Extended Security Negotiation : Extended security negotiation is not supported and send mechType KRB5 in the same packet. Could you please provide a workaround before the Netapp bugfix ? In the meantime I create my own patch, it's working for me but I'm not really sure of what I'm doing. --- cifssmb.c.old 2009-09-01 16:16:32.000000000 +0200 +++ cifssmb.c 2009-09-01 14:20:34.000000000 +0200 @@ -647,7 +647,8 @@ if (pSMBr->EncryptionKeyLength == CIFS_CRYPTO_KEY_SIZE) { memcpy(server->cryptKey, pSMBr->u.EncryptionKey, CIFS_CRYPTO_KEY_SIZE); - } else if ((pSMBr->hdr.Flags2 & SMBFLG2_EXT_SEC) + } else if (((pSMBr->hdr.Flags2 & SMBFLG2_EXT_SEC) + || (server->capabilities & CAP_EXTENDED_SECURITY)) && (pSMBr->EncryptionKeyLength == 0)) { /* decode security blob */ } else if (server->secMode & SECMODE_PW_ENCRYPT) { @@ -657,7 +658,7 @@ /* BB might be helpful to save off the domain of server here */ - if ((pSMBr->hdr.Flags2 & SMBFLG2_EXT_SEC) && + if ((pSMBr->hdr.Flags2 & SMBFLG2_EXT_SEC) || (server->capabilities & CAP_EXTENDED_SECURITY)) { count = pSMBr->ByteCount; if (count < 16) {
That doesn't quite look right... Just because the server supports extended security we can't assume that we're actually using extended security. I think we'll need to do something different if we want to work around this netapp bug.
We are experiencing this bug too. I understand the proposed patch is imperfect, but we will give it a whirl anyway. If anybody have a better fix to propose, we might be able to test.
We did some test with the patch proposed by Thomas. It does work, although not with sec=krb5i (we had to specify sec=krb5). I understand the patch might not be the right way to resolve the problem, but it does point to the problem being where Thomas think it is indeed. If anybody would have a better patch to test, I would be a taker. However, I may not have access to the NetApp Filer on a regular basis in the future to test. I have also reported the bug against Ubuntu in Launchpad: https://bugs.launchpad.net/samba/+bug/479272 Many thanks
We are also hit by this and I would like to make some remarks: 1. I think we forget one very important point: windows clients can mount these shares! Windows clients ignore the SMBFLG2_EXT_SEC in the SMB_COM_NEGOTIATE response, Linux clients behave different than Windows clients in this point! 2. If I found the right part in the Microsoft documentation (http://msdn.microsoft.com/en-us/library/cc246254%28PROT.13%29.aspx) it says: 2.2.1, scroll down to SMB_FLAGS2_EXTENDED_SECURITY: "Indicates that the client or server supports SPNEGO authentication, as specified in section 3.2.4.2.3 for client behavior and sections 3.3.5.2 and 3.3.5.3 for server behavior. This bit field SHOULD be set to 1 when NTLM 0.12 or later is negotiated for the SMB dialect dialect and the client or server supports extended security." The say *SHOULD*, not *MUST*... I've also looked at 3.3.5.2 and 3.3.5.3 but did not find any MUST's for the server response about this flag, please correct me if I got it wrong. So the behavior of the netapp might be perfectly legal and not a bug? 3. What are the advantages for the client on insisting that SMBFLG2_EXT_SEC is set? What could happen in the worst case if CAP_EXTENDED_SECURITY is set but SMBFLG2_EXT_SEC not? 4. For economical thinking companys it is very good if Linux clients cannot use cifs. Customers have to buy CIFS *and* NFS licenses which is very good for revenue. ;-)
We are having trouble with this too. Is there already a permanent fix available ? We tried samba 3.5.11, but also the same result.
Is this still a problem with the latest cifs module (such as 1.75)?
The cifs module version 1.61 has this problem. I do not know if 1.75 still has this problem. I will try to test this.
cifs.ko version 1.74 works good with a mount.cifs/krb5 to a netapp filer. So this looks fixed.
Excellent. Thanks for testing it.