Christian Garling
2017-Jun-09 18:51 UTC
[Samba] mount.cifs fails with protocol SMBv2.x on a DFS share
Hello list, a few days ago we migrated our shares to a DFS cluster, also we disabled SMBv1 protocol. Now we are no longer able to connect to the shares with our linux workstations. The setup looks like this: linux workstation -----> AD server (Windows Server 2008 R2) -----> file server (Windows Server 2016, running in 2008 R2 compat mode) I have searched the web for a solution on the last few days. Mostly it came down to this: Take care that smbclient, cifs-utils and keyutils is installed. Also have these lines in /etc/request-key.conf: create cifs.spnego * * /usr/sbin/cifs.upcall %k create dns_resolver * * /usr/sbin/cifs.upcall %k My setup satisfies these requirements. I have tried the connection with these commands (I replaced our domain with example.com): mount -v -t cifs //office.example.com/technik /mnt/dfs -o username=c.garling,domain=OFFICE,vers=2.0 mount -v -t cifs //office.example.com/technik /mnt/dfs -o username=c.garling,domain=OFFICE,vers=2.1 If I do so I can see this in tcpdump: 100.392000390 192.168.23.107 -> 192.168.15.6 SMB2 172 Negotiate Protocol Request 100.393121936 192.168.15.6 -> 192.168.23.107 SMB2 318 Negotiate Protocol Response 100.393223968 192.168.23.107 -> 192.168.15.6 SMB2 190 Session Setup Request, NTLMSSP_NEGOTIATE 100.394178092 192.168.15.6 -> 192.168.23.107 SMB2 390 Session Setup Response, Error: STATUS_MORE_PROCESSING_REQUIRED, NTLMSSP_CHALLENGE 100.394295512 192.168.23.107 -> 192.168.15.6 SMB2 494 Session Setup Request, NTLMSSP_AUTH, User: OFFICE\c.garling 100.397795864 192.168.15.6 -> 192.168.23.107 SMB2 142 Session Setup Response 100.397895000 192.168.23.107 -> 192.168.15.6 SMB2 198 Tree Connect Request Tree: \\office.example.com\technik 100.398866908 192.168.15.6 -> 192.168.23.107 SMB2 143 Tree Connect Response, Error: STATUS_BAD_NETWORK_NAME My client directly tries to connect to the share on 192.168.15.6, but this is the AD server that should forward to 192.168.15.17 which is the file server. I also traced the connection attempt with wireshark. In the request sent from my workstation I found this message in the flags: "This host does NOT support DFS." We re-enabled SMBv1 for testing purposes. With SMBv1 the connection to the DFS works with the command above but vers=1.0. I can not figure out why DFS does not work when vers=2.0 or vers=2.1 will be used. We tested some different distros (Linux Mint 18.1, Debian 8, Debian 9, Gentoo) with different kernel versions. Please ask me for further information, if I missed something. Any help is welcome! Regards, Christian Garling
L A Walsh
2017-Jun-10 21:23 UTC
[Samba] mount.cifs fails with protocol SMBv2.x on a DFS share
Christian Garling via samba wrote:> Take care that smbclient, cifs-utils and keyutils is installed. Also > have these lines in /etc/request-key.conf: > > create cifs.spnego * * /usr/sbin/cifs.upcall %k > create dns_resolver * * /usr/sbin/cifs.upcall %k > > My setup satisfies these requirements. I have tried the connection > with these commands (I replaced our domain with example.com): > > mount -v -t cifs //office.example.com/technik /mnt/dfs -o > username=c.garling,domain=OFFICE,vers=2.0 > mount -v -t cifs //office.example.com/technik /mnt/dfs -o > username=c.garling,domain=OFFICE,vers=2.1Isn't "mount.cifs" and the upcall stuff under the "linux-cifs" project -- a separate project from samba these days? Someone on the samba list might know the answers, but if you are having a problem with the linux mount.cifs command mounting a Windows CIFS share you might find more help on the linux-cifs list (@vger.kernel.org). Looking at your dump, I saw a weirdity:> > If I do so I can see this in tcpdump: > ... > 100.394295512 192.168.23.107 -> 192.168.15.6 SMB2 494 Session Setup > Request, NTLMSSP_AUTH, User: OFFICE\c.garling > 100.397795864 192.168.15.6 -> 192.168.23.107 SMB2 142 Session Setup > Response > 100.397895000 192.168.23.107 -> 192.168.15.6 SMB2 198 Tree Connect > Request Tree: \\office.example.com\technik > 100.398866908 192.168.15.6 -> 192.168.23.107 SMB2 143 Tree Connect > Response, Error: STATUS_BAD_NETWORK_NAME\\office.example.com doesn't look like a valid machine name. Do you have any idea how you might be getting from User 'OFFICE\c.garling' to a rather odd looking machine name (or did you just substitute that in?)...
Yes, I know, XP-SP3 is very old. It works for what I need it for. I have some programs that will never be updated for Win 7. Note that XP-SP3 and Fedora 14 work together just fine, so I'm guessing that a newer version of Samba is what is keeping me from logging in from XP. But, I do not know what to put in the smb.conf file to allow XP to mount a share. Here is the output from testparm: Load smb config files from /etc/samba/smb.conf rlimit_max: increasing rlimit_max (1024) to minimum Windows limit (16384) Processing section "[homes]" Processing section "[usenet]" Processing section "[video]" Processing section "[website]" Processing section "[tmp]" Loaded services file OK. Server role: ROLE_STANDALONE # Global parameters [global] server string = Linux Samba Server workgroup = VIDIOT log file = /var/log/samba/log.%m max log size = 50 security = USER idmap config * : backend = tdb cups options = raw hosts allow = 127. 192.168.1. [homes] comment = Home Directories browseable = No read only = No [usenet] comment = Linux usenet area path = /WebDisk/share_download/usenet read only = No [video] comment = Video Files Workspace path = /WebDisk/ftp/pub read only = No [website] comment = Web Server HTML Area path = /WebDisk/http/htdocs/vidiot read only = No [tmp] comment = Temporary file space path = /WebDisk/tmp guest ok = Yes read only = No When I try and map "W: \\192.168.1.11\website" and use brown as the login name and my password, it goes off to do its thing and a wee bit later it comes back with the login GUI. The only entries in the log file are those resulting from stopping and starting the smb service with restart (in order to reread the config file). Tried it with encryption of the password with yes (default) and no. Thanks for any tips that might fix this issue. MB -- e-mail: vidiot at vidiot.com | vidiot at vidiot.net /~\ The ASCII 6082066843 at email.uscc.net (140 char limit) \ / Ribbon Campaign Visit - URL: http://vidiot.com/ X Against http://vidiot.net/ / \ HTML Email "You're Sherlock Holmes, wear the damn hat!" - Watson to Sherlock Sherlock - The Abominable Bride - 1/01/16
Aurélien Aptel
2017-Jun-12 10:46 UTC
[Samba] mount.cifs fails with protocol SMBv2.x on a DFS share
Hi Christian, Christian Garling via samba <samba at lists.samba.org> writes:> a few days ago we migrated our shares to a DFS cluster, also we disabled > SMBv1 protocol. Now we are no longer able to connect to the shares with > our linux workstations. The setup looks like this:Regardless of you dns config, you need a fairly recent kernel (4.11 or above) to support DFS with SMB2+. -- Aurélien Aptel / SUSE Labs Samba Team GPG: 1839 CB5F 9F5B FB9B AA97 8C99 03C8 A49B 521B D5D3 SUSE Linux GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg)
Christian Garling
2017-Jun-12 10:54 UTC
[Samba] mount.cifs fails with protocol SMBv2.x on a DFS share
Hi Aurélien, is there some documentation around where I can read about that? Where can I find the information, that I need Kernel 4.11 or above to get DFS with SMB2.0 / 2.1 / 3.0 and above working? Regards, Christian Am 12.06.2017 um 12:46 schrieb Aurélien Aptel:> Hi Christian, > > Christian Garling via samba <samba at lists.samba.org> writes: >> a few days ago we migrated our shares to a DFS cluster, also we disabled >> SMBv1 protocol. Now we are no longer able to connect to the shares with >> our linux workstations. The setup looks like this: > Regardless of you dns config, you need a fairly recent kernel (4.11 or > above) to support DFS with SMB2+. >
Seemingly Similar Threads
- [regression drm/noveau] suspend to ram -> BOOM: exception RIP: drm_calc_vbltimestamp_from_scanoutpos+335
- mount.cifs fails with protocol SMBv2.x on a DFS share
- [regression drm/noveau] suspend to ram -> BOOM: exception RIP: drm_calc_vbltimestamp_from_scanoutpos+335
- [regression drm/noveau] suspend to ram -> BOOM: exception RIP: drm_calc_vbltimestamp_from_scanoutpos+335
- Share mounts in SMBv1 mode, but fails weirdly in SMBv2 mode