Okay, In the current situation we have a windows-served fileshare "fs/share", an AD account "fsuser", and a linux client "fsclient". "fsuser" is a restricted account which can only log in to a small number of machines (including "fs"). The account itself is okay, and in fact can be used to connect to the share without problem using smbclient. However, when attempting to mount.cifs the share, we get a server response: admin@fsclient:~$ sudo mount -t cifs -o 'username=fsuser,password=fspass' //fs/share /mnt mount error(13): Permission denied Refer to the mount.cifs(8) manual page (e.g. man mount.cifs) dmesg: [91939.877791] Status code returned 0xc0000070 NT_STATUS_INVALID_WORKSTATION [91939.877804] CIFS VFS: Send error in SessSetup = -13 [91939.877811] CIFS VFS: cifs_mount failed w/return code = -13 Looking at a packet capture, it does not seem as though "fsclient" is included anywhere in the initial SetupAndX request, which then fails with the above NT error code. However, looking at a packet capture of smbclient (which does NTLMSSP instead of straight ntlm, in case it matters), "fsclient" is in fact included as a parameter in the negotiation process. So i spent a while R'ing TFM on mount.cifs, and found this option: netbiosname=arg When mounting to servers via port 139, specifies the RFC1001 source name to use to represent the client netbios machine name when doing the RFC1001 netbios session initialize. Which does not seem to have any effect when using the default (445) port. In desperation I tried mounting with port=139, and lo and behold, it mounts (without specifying netbiosname even). It seems when mounting specifying port=139 there's an additional NetBios session request with the fileshare that otherwise does not occur. So I believe either (a) when mounting on port 445 this netbios session request should still be (by default, or an extra option) performed, or (b) the client workstation name should otherwise somehow be included in the SetupAndX request on port 445. Note that I have not attached any packet captures to the bug due to the sensitive nature of their contents, but can provide such things out-of-band to any devs that need it (though it should be pretty easy to reproduce).
I don't think so: http://msdn.microsoft.com/en-us/library/cc246249%28v=PROT.13%29.aspx IIUC, when the connection is done on port 445, then SMB is layered directly on top of TCP, without any of the NetBIOS goop in between. What might be helpful is some captures that show what smbclient is doing in your situation.
Sean sent me some captures. The big difference is that smbclient is using NTLMSSP to authenticate. I suspect that using sec=ntlmssp on a recent kernel will also work. It certainly would be nice if this were more automatic in cifs. I tried to fix that a year or two ago, but Steve wanted something that allowed you to specify multiple sec= options at a time: http://lists.samba.org/archive/linux-cifs-client/2010-April/005830.html I didn't have time to re-do the whole set for that. Perhaps someone else would want to now.
agreed, and newish (2.6.38 -- 3.0ish) kernels seem to work with sec=ntlmssp. Reading through the MS docs, it seems that the packet format for SessionSetupAndX ([MS-CIFS] 2.2.4.53) doesn't include a way to specify the client workstation without either having the netbios stuff prepended or using NTLMSSP (which is probably the "real" fix here). BTW, it seems that with older "LTS" kernels (ubuntu lucid == 2.6.32 + backports), sec=ntlmssp is entirely broken: mount error(2): No such file or directory Refer to the mount.cifs(8) manual page (e.g. man mount.cifs) But at least we have the port=139 workaround in the meantime :) But for this bug, I think you can either close it (works with ntlmssp on newer kernels), or repurpose it to track the eventual progress for the patchset you referenced.