Hi, I have a problem with DFS root referrals. Setup: - Two domain controllers, a.domain and b.domain - a.domain is DFS root for \\domain\share - DNS points domain to b.domain (Yes, I know that is inconsistent but I found quite common in real implementations as most firms have multiple DCs in their domain DNS entry but only one or few of them are DFS roots) Behavior of various clients: - Windows: Entering \\domain\share in the "run" box works and shows the folders in the share. - Linux: smbclient -U user '\\domain\share' works. dir shows the folders - Linux: mount.cifs '\\domain\share' \tmp\mnt -o username=user fails with mount error(6): No such device or address Doing some debugging the reason becomes obvious: Tracing smbclient, smbclient makes contact with the domain controller and sends a SMB_COM_TRANSACTION2 command with subcommand TRANS2_GET_DFS_REFERRAL. The DC responds with \\domain\share referred to \\a\share Connecting to \\a\share suceeds. Running mount.cifs with -v gives as output: mount.cifs kernel mount options: unc=//DOMAIN\SHARE,ver=1,username=user,,,,,,,,ip=10.146.1.100,pass=******** The IP is the IP of b, i.e., mount.cifs does a simple DNS lookup. - This was tested on a Ubuntu Lucid systems with 3.4.7 and the 2.6.32-25-generic kernel. - keyutils and the upcall configuration are in place as redirects are working.
I believe Steve just committed some patches from Sean Finney that may fix this. Thomas, Is there a way for you to test the latest patches in Steve French's git tree? http://git.kernel.org/?p=linux/kernel/git/sfrench/cifs-2.6.git
I will try to get this tested within the next week. I will let you know. Thanks Thomas
Preliminary: It seems fixed ... but I still did not get it to work. Here is what I did: - I got the 2.6.39 kernel off kernel.org and today's git patch (2.6.39-git9). - I checked that the expand_dfs_referral function is in the source in fs/cifs/connect.c - After compiling and installing the kernel, I ran the following command: mount --verbose -t cifs //domain.com/share/Users /tmp/mnt -o dir_mode=0755,file_mode=0644,gid=100,iocharset=utf8,nocase,perm,uid=505,user=DOMAIN/user I got the following issues: * Mount error 2 with the following log: May 24 16:00:07 viatest5 kernel: fs/cifs/connect.c: Security Mode: 0xf Capabilities: 0x1f3fd TimeAdjust: 25200 May 24 16:00:07 viatest5 kernel: fs/cifs/sess.c: sess setup type 1 May 24 16:00:07 viatest5 kernel: CIFS VFS: could not allocate des crypto API May 24 16:00:07 viatest5 kernel: May 24 16:00:07 viatest5 kernel: fs/cifs/cifsencrypt.c: setup_ntlm_response Can't generate NTLM response, error: -2 May 24 16:00:07 viatest5 kernel: CIFS VFS: Error -2 during NTLM authentication May 24 16:00:07 viatest5 kernel: fs/cifs/sess.c: ssetup freeing small buf ffff880106010140 I found references to this error with the MD4 API when it is not compiled into the kernel but I checked, the API is compiled into the kernel: egrep 'CRYPTO_(DES|MD)' /boot/config-2.6.39-git9.110525 CONFIG_CRYPTO_MD4=y CONFIG_CRYPTO_MD5=y CONFIG_CRYPTO_DES=y I got stuck here. This happens independent of whether or not I use a DFS share or a standard share. * I added ",sec=ntlmv2i" to the command line and got mount error 22: May 24 14:38:57 viatest5 kernel: fs/cifs/transport.c: sync_mid_result: cmd=115 mid=2 state=4 May 24 14:38:57 viatest5 kernel: CIFS VFS: Unexpected SMB signature May 24 14:38:57 viatest5 kernel: Status code returned 0xc000000d NT_STATUS_INVALID_PARAMETER May 24 14:38:57 viatest5 kernel: fs/cifs/netmisc.c: Mapping smb error code 0xc000000d to POSIX err -22 May 24 14:38:57 viatest5 kernel: fs/cifs/misc.c: Null buffer passed to cifs_small_buf_release May 24 14:38:57 viatest5 kernel: fs/cifs/sess.c: ssetup freeing small buf ffff8800ab05ecc0 May 24 14:38:57 viatest5 kernel: CIFS VFS: Send error in SessSetup = -22 May 24 14:38:57 viatest5 kernel: fs/cifs/connect.c: CIFS VFS: leaving cifs_get_smb_ses (xid = 869) rc = -22 * I applied Microsoft fix from KB 957441 http://support.microsoft.com/kb/957441 This fixed that issue and I got error 95 ... however: - The client DNS resolves DOMAIN.COM to our secondary AD server (sibi). - Then, goes to our secondary AD server and retrieves the info that the DFS ROOT is on the primary AD server (ibis) - Then, goes to our primary AD server and finds that Users is on the file server (files) - Then, goes to our fileserver files and fails as this one does not support signed requested. Thus, I think that the original issue I filed is fixed as the client gets handed through all the right steps. Yet, I have two issues left: - Why do I get the des Crypto API error even though it is compiled into the kernel? - How do I specify the the individual systems require different security protocols? Thanks for your support Thomas
I'm experiencing a similar problem. - Three domain controllers a, b, c. - Only a and b are dfs roots - DNS points to a, b, and c One out of three mount attempts fails, which makes sense, since one out of three DNS requests returns c. mount.cifs version: 5.1 Thomas pointed out that a setup like this is inconsistent. Could anybody point me to a document that shows that this setup is indeed inconsistent? smbclient and Windows seem to be handling this situation without complaints. Or is this indeed a valid setup which means that this bug needs to be fixed? Thanks.
> > Yet, I have two issues left: > - Why do I get the des Crypto API error even though it is compiled into the > kernel? That was a bug and should now be fixed. > - How do I specify the the individual systems require different security > protocols? I'm afraid that's not possible at the moment. cifs.ko's ability to autonegotiate security is woefully lacking. However, cifs does autonegotiate signing, so if you mount with sec=ntlmv2 and the server requires signing then it should auto negotiate it on. If however, you say sec=ntlmv2i and the server at the end of the referral does not support signing then you're out of luck. I'm not sure how we can sanely support that, TBH. It's a bit of a user interface issue since chasing referrals should be a transparent process. I'll go ahead and close this bug. Please reopen it if you wish to discuss it further.
(In reply to comment #4) > I'm experiencing a similar problem. > > - Three domain controllers a, b, c. > - Only a and b are dfs roots > - DNS points to a, b, and c > > One out of three mount attempts fails, which makes sense, since one out of > three DNS requests returns c. > > mount.cifs version: 5.1 > > Thomas pointed out that a setup like this is inconsistent. Could anybody point > me to a document that shows that this setup is indeed inconsistent? smbclient > and Windows seem to be handling this situation without complaints. > > Or is this indeed a valid setup which means that this bug needs to be fixed? > > Thanks. I'm a little confused on this. Since the original bug against which this is filed is now fixed, perhaps you could open a new bug with more details and I'll take a look when I'm able?