Gavin Greenwalt
2021-Apr-01 16:44 UTC
[Samba] Windows clients connecting to SMB share differently over IP than DNS
I have a CIFS share on a samba server ((Version 4.4.16)) joined as a member to a Windows 2012 R2 AD domain. If I on a windows 10 machine mount the share over IP address it takes about 14.5 minutes for 21,000 files to copy. (which is in of itself slow but I believe due to a lack of official SMB3 multichannel support in Samba.) If I mount the share with the DNS name it takes *205* minutes to copy the 21,000 files to copy. More than 10x slower. Connecting to the IP address (e.g. \\1.1.1.1\share) the SMB transaction goes as expected. 5153 19.122016 2.2.2.2 1.1.1.1 Create Request File: temp\Folder\1 - Copy (83).txt 5154 19.122612 1.1.1.1 2.2.2.2 Create Response File: temp\Folder\1 - Copy (83).txt 5155 19.122716 2.2.2.2 1.1.1.1 SetInfo Request FILE_INFO/SMB2_FILE_ENDOFFILE_INFO File: temp\Folder\1 - Copy (83).txt 5156 19.122886 1.1.1.1 2.2.2.2 SetInfo Response 5157 19.122951 2.2.2.2 1.1.1.1 Write Request Len:8888 Off:0 File: temp\Folder\1 - Copy (83).txt 5159 19.123135 1.1.1.1 2.2.2.2 Write Response 5160 19.123165 2.2.2.2 1.1.1.1 SetInfo Request FILE_INFO/SMB2_FILE_BASIC_INFO File: temp\Folder\1 - Copy (83).txt 5161 19.123308 1.1.1.1 2.2.2.2 SetInfo Response 5162 19.123338 2.2.2.2 1.1.1.1 GetInfo Request FILE_INFO/SMB2_FILE_NETWORK_OPEN_INFO File: temp\Folder\1 - Copy (83).txt 5163 19.123420 1.1.1.1 2.2.2.2 GetInfo Response 5164 19.123541 2.2.2.2 1.1.1.1 GetInfo Request FILE_INFO/SMB2_FILE_NETWORK_OPEN_INFO File: temp\Folder\1 - Copy (83).txt 5165 19.123616 1.1.1.1 2.2.2.2 GetInfo Response 5166 19.123666 2.2.2.2 1.1.1.1 GetInfo Request SEC_INFO/SMB2_SEC_INFO_00 File: temp\Folder\1 - Copy (83).txt 5167 19.127104 1.1.1.1 2.2.2.2 GetInfo Response, Error: STATUS_BUFFER_TOO_SMALL 5168 19.127171 2.2.2.2 1.1.1.1 GetInfo Request SEC_INFO/SMB2_SEC_INFO_00 File: temp\Folder\1 - Copy (83).txt 5169 19.130321 1.1.1.1 2.2.2.2 GetInfo Response 5170 19.130584 2.2.2.2 1.1.1.1 Close Request File: temp\Folder\1 - Copy (83).txt 5171 19.130800 1.1.1.1 2.2.2.2 Close Response Over DNS (e.g. \\server\share) things screech to a halt and follow a completely different transaction loop involving a tree connect request over every single file. This slows things down to about 1 file/second. 4365 9.064473 2.2.2.2 1.1.1.1 Session Setup Request 4367 9.067749 2.2.2.2 1.1.1.1 Create Request File: temp\Folder\1 - Copy (83).txt 4749 10.061721 2.2.2.2 1.1.1.1 Create Request File: temp\Folder 4755 10.068555 1.1.1.1 2.2.2.2 Session Setup Response 4756 10.068922 2.2.2.2 1.1.1.1 Tree Connect Request Tree: \\Synology\Share 4757 10.069262 1.1.1.1 2.2.2.2 Create Response File: temp\Folder\1 - Copy (83).txt 4758 10.069483 2.2.2.2 1.1.1.1 SetInfo Request FILE_INFO/SMB2_FILE_ENDOFFILE_INFO File: temp\Folder\1 - Copy (83).txt 4759 10.069613 1.1.1.1 2.2.2.2 Create Response File: temp\Folder 4760 10.069729 2.2.2.2 1.1.1.1 Find Request File: temp\Folder SMB2_FIND_ID_BOTH_DIRECTORY_INFO Pattern: *;Find Request File: temp\Folder SMB2_FIND_ID_BOTH_DIRECTORY_INFO Pattern: * 4762 10.074482 1.1.1.1 2.2.2.2 Tree Connect Response, Error: STATUS_ACCESS_DENIED 4763 10.074550 2.2.2.2 1.1.1.1 Session Logoff Request 4764 10.074688 1.1.1.1 2.2.2.2 SetInfo Response 4765 10.074810 2.2.2.2 1.1.1.1 Write Request Len:8888 Off:0 File: temp\Folder\1 - Copy (83).txt 4767 10.077222 1.1.1.1 2.2.2.2 Response;Find Response, Error: STATUS_NO_MORE_FILES 4769 10.077405 1.1.1.1 2.2.2.2 Session Logoff Response 4770 10.077448 2.2.2.2 1.1.1.1 Close Request File: temp\Folder 4771 10.077535 1.1.1.1 2.2.2.2 Write Response 4772 10.077630 1.1.1.1 2.2.2.2 Close Response 4774 10.077712 2.2.2.2 1.1.1.1 SetInfo Request FILE_INFO/SMB2_FILE_BASIC_INFO File: temp\Folder\1 - Copy (83).txt 4775 10.077872 2.2.2.2 1.1.1.1 Create Request File: temp\Folder 4776 10.078096 1.1.1.1 2.2.2.2 SetInfo Response 4777 10.078166 2.2.2.2 1.1.1.1 GetInfo Request FILE_INFO/SMB2_FILE_NETWORK_OPEN_INFO File: temp\Folder\1 - Copy (83).txt 4778 10.078337 1.1.1.1 2.2.2.2 Create Response File: temp\Folder 4779 10.078378 1.1.1.1 2.2.2.2 GetInfo Response 4781 10.078430 2.2.2.2 1.1.1.1 Close Request File: temp\Folder 4782 10.078550 1.1.1.1 2.2.2.2 Close Response 4783 10.078648 2.2.2.2 1.1.1.1 GetInfo Request FILE_INFO/SMB2_FILE_NETWORK_OPEN_INFO File: temp\Folder\1 - Copy (83).txt 4784 10.078670 2.2.2.2 1.1.1.1 Create Request File: temp 4785 10.078748 1.1.1.1 2.2.2.2 GetInfo Response 4786 10.078821 2.2.2.2 1.1.1.1 GetInfo Request SEC_INFO/SMB2_SEC_INFO_00 File: temp\Folder\1 - Copy (83).txt 4787 10.078897 1.1.1.1 2.2.2.2 Create Response File: temp 4788 10.078998 2.2.2.2 1.1.1.1 Close Request File: temp 4789 10.083060 1.1.1.1 2.2.2.2 GetInfo Response, Error: STATUS_BUFFER_TOO_SMALL 4790 10.083148 1.1.1.1 2.2.2.2 Close Response 4791 10.083155 2.2.2.2 1.1.1.1 GetInfo Request SEC_INFO/SMB2_SEC_INFO_00 File: temp\Folder\1 - Copy (83).txt 4792 10.083252 2.2.2.2 1.1.1.1 Create Request File: 4793 10.087615 1.1.1.1 2.2.2.2 GetInfo Response 4794 10.087860 1.1.1.1 2.2.2.2 Create Response File: 4796 10.087948 2.2.2.2 1.1.1.1 Find Request File: SMB2_FIND_ID_BOTH_DIRECTORY_INFO Pattern: *;Find Request File: SMB2_FIND_ID_BOTH_DIRECTORY_INFO Pattern: * 4797 10.088101 2.2.2.2 1.1.1.1 Close Request File: temp\Folder\1 - Copy (83).txt 4798 10.089075 1.1.1.1 2.2.2.2 Find Response;Find Response, Error: STATUS_NO_MORE_FILES 4800 10.089169 2.2.2.2 1.1.1.1 Close Request File: 4801 10.089291 1.1.1.1 2.2.2.2 Close Response 4802 10.089375 1.1.1.1 2.2.2.2 Close Response The initial delay seems to be somewhat random. E.g. but consistenly around 1second per file for the negotiation. 11686 28.24ms 2.2.2.2 1.1.1.1 Session Setup Request 11688 28.24ms 2.2.2.2 1.1.1.1 Create Request File: temp\Folder\1 - Copy (114).txt 11997 28.74ms 2.2.2.2 1.1.1.1 Create Request File: temp\Folder\Files 12079 28.99ms 1.1.1.1 2.2.2.2 Session Setup Response 12080 28.99ms 2.2.2.2 1.1.1.1 Tree Connect Request Tree: \\Synology\Share Do windows clients connect to \\path\shares differently from \\ip.ad.d.ress\paths? I?m kind of stuck trying to think of what else to test to make progress on why the server is so much slower on Windows 10 clients when mapped over DNS name. Windows reports the smb connection as a 3.1.1 dialect for both \\ip and \\dns. The only intriguing thing I can note is that Windows connects to the \\ip address as domain\user for credentials. However no matter what I do it connects as domain*.com*\user for named server connections (both Windows and Linux\samba). For comparison a Windows 2012R2 file server and a Windows 10 desktop client follow the correct (fast\streamlined) SMB transaction with both DNS and IP Address. So it seems to be limited to the Samba share. - Gavin Greenwalt
Jeremy Allison
2021-Apr-01 16:50 UTC
[Samba] Windows clients connecting to SMB share differently over IP than DNS
On Thu, Apr 01, 2021 at 09:44:40AM -0700, Gavin Greenwalt via samba wrote:>I have a CIFS share on a samba server ((Version 4.4.16)) joined as a member >to a Windows 2012 R2 AD domain. If I on a windows 10 machine mount the >share over IP address it takes about 14.5 minutes for 21,000 files to copy. >(which is in of itself slow but I believe due to a lack of official SMB3 >multichannel support in Samba.) If I mount the share with the DNS name it >takes *205* minutes to copy the 21,000 files to copy. More than 10x >slower. > >Connecting to the IP address (e.g. \\1.1.1.1\share) the SMB transaction >goes as expected. > >5153 19.122016 2.2.2.2 1.1.1.1 Create Request File: >temp\Folder\1 - Copy (83).txt > >5154 19.122612 1.1.1.1 2.2.2.2 Create Response File: >temp\Folder\1 - Copy (83).txt > >5155 19.122716 2.2.2.2 1.1.1.1 SetInfo Request >FILE_INFO/SMB2_FILE_ENDOFFILE_INFO File: temp\Folder\1 - Copy (83).txt > >5156 19.122886 1.1.1.1 2.2.2.2 SetInfo Response > >5157 19.122951 2.2.2.2 1.1.1.1 Write Request Len:8888 >Off:0 File: temp\Folder\1 - Copy (83).txt > >5159 19.123135 1.1.1.1 2.2.2.2 Write Response > >5160 19.123165 2.2.2.2 1.1.1.1 SetInfo Request >FILE_INFO/SMB2_FILE_BASIC_INFO File: temp\Folder\1 - Copy (83).txt > >5161 19.123308 1.1.1.1 2.2.2.2 SetInfo Response > >5162 19.123338 2.2.2.2 1.1.1.1 GetInfo Request >FILE_INFO/SMB2_FILE_NETWORK_OPEN_INFO File: temp\Folder\1 - Copy (83).txt > >5163 19.123420 1.1.1.1 2.2.2.2 GetInfo Response > >5164 19.123541 2.2.2.2 1.1.1.1 GetInfo Request >FILE_INFO/SMB2_FILE_NETWORK_OPEN_INFO File: temp\Folder\1 - Copy (83).txt > >5165 19.123616 1.1.1.1 2.2.2.2 GetInfo Response > >5166 19.123666 2.2.2.2 1.1.1.1 GetInfo Request >SEC_INFO/SMB2_SEC_INFO_00 File: temp\Folder\1 - Copy (83).txt > >5167 19.127104 1.1.1.1 2.2.2.2 GetInfo Response, >Error: STATUS_BUFFER_TOO_SMALL > >5168 19.127171 2.2.2.2 1.1.1.1 GetInfo Request >SEC_INFO/SMB2_SEC_INFO_00 File: temp\Folder\1 - Copy (83).txt > >5169 19.130321 1.1.1.1 2.2.2.2 GetInfo Response > >5170 19.130584 2.2.2.2 1.1.1.1 Close Request File: >temp\Folder\1 - Copy (83).txt > >5171 19.130800 1.1.1.1 2.2.2.2 Close Response > > > >Over DNS (e.g. \\server\share) things screech to a halt and follow a >completely different transaction loop involving a tree connect request over >every single file. This slows things down to about 1 file/second. > > > >4365 9.064473 2.2.2.2 1.1.1.1 Session Setup Request > >4367 9.067749 2.2.2.2 1.1.1.1 Create Request File: >temp\Folder\1 - Copy (83).txt > >4749 10.061721 2.2.2.2 1.1.1.1 Create Request File: >temp\Folder > >4755 10.068555 1.1.1.1 2.2.2.2 Session Setup Response > >4756 10.068922 2.2.2.2 1.1.1.1 Tree Connect Request >Tree: \\Synology\Share > >4757 10.069262 1.1.1.1 2.2.2.2 Create Response File: >temp\Folder\1 - Copy (83).txt > >4758 10.069483 2.2.2.2 1.1.1.1 SetInfo Request >FILE_INFO/SMB2_FILE_ENDOFFILE_INFO File: temp\Folder\1 - Copy (83).txt > >4759 10.069613 1.1.1.1 2.2.2.2 Create Response File: >temp\Folder > >4760 10.069729 2.2.2.2 1.1.1.1 Find Request File: >temp\Folder SMB2_FIND_ID_BOTH_DIRECTORY_INFO Pattern: *;Find Request File: >temp\Folder SMB2_FIND_ID_BOTH_DIRECTORY_INFO Pattern: * > >4762 10.074482 1.1.1.1 2.2.2.2 Tree Connect Response, >Error: STATUS_ACCESS_DENIED > >4763 10.074550 2.2.2.2 1.1.1.1 Session Logoff Request > >4764 10.074688 1.1.1.1 2.2.2.2 SetInfo Response > >4765 10.074810 2.2.2.2 1.1.1.1 Write Request Len:8888 >Off:0 File: temp\Folder\1 - Copy (83).txt > >4767 10.077222 1.1.1.1 2.2.2.2 Response;Find Response, >Error: STATUS_NO_MORE_FILES > >4769 10.077405 1.1.1.1 2.2.2.2 Session Logoff Response > >4770 10.077448 2.2.2.2 1.1.1.1 Close Request File: >temp\Folder > >4771 10.077535 1.1.1.1 2.2.2.2 Write Response > >4772 10.077630 1.1.1.1 2.2.2.2 Close Response > >4774 10.077712 2.2.2.2 1.1.1.1 SetInfo Request >FILE_INFO/SMB2_FILE_BASIC_INFO File: temp\Folder\1 - Copy (83).txt > >4775 10.077872 2.2.2.2 1.1.1.1 Create Request File: >temp\Folder > >4776 10.078096 1.1.1.1 2.2.2.2 SetInfo Response > >4777 10.078166 2.2.2.2 1.1.1.1 GetInfo Request >FILE_INFO/SMB2_FILE_NETWORK_OPEN_INFO File: temp\Folder\1 - Copy (83).txt > >4778 10.078337 1.1.1.1 2.2.2.2 Create Response File: >temp\Folder > >4779 10.078378 1.1.1.1 2.2.2.2 GetInfo Response > >4781 10.078430 2.2.2.2 1.1.1.1 Close Request File: >temp\Folder > >4782 10.078550 1.1.1.1 2.2.2.2 Close Response > >4783 10.078648 2.2.2.2 1.1.1.1 GetInfo Request >FILE_INFO/SMB2_FILE_NETWORK_OPEN_INFO File: temp\Folder\1 - Copy (83).txt > >4784 10.078670 2.2.2.2 1.1.1.1 Create Request File: >temp > >4785 10.078748 1.1.1.1 2.2.2.2 GetInfo Response > >4786 10.078821 2.2.2.2 1.1.1.1 GetInfo Request >SEC_INFO/SMB2_SEC_INFO_00 File: temp\Folder\1 - Copy (83).txt > >4787 10.078897 1.1.1.1 2.2.2.2 Create Response File: >temp > >4788 10.078998 2.2.2.2 1.1.1.1 Close Request File: temp > >4789 10.083060 1.1.1.1 2.2.2.2 GetInfo Response, >Error: STATUS_BUFFER_TOO_SMALL > >4790 10.083148 1.1.1.1 2.2.2.2 Close Response > >4791 10.083155 2.2.2.2 1.1.1.1 GetInfo Request >SEC_INFO/SMB2_SEC_INFO_00 File: temp\Folder\1 - Copy (83).txt > >4792 10.083252 2.2.2.2 1.1.1.1 Create Request File: > >4793 10.087615 1.1.1.1 2.2.2.2 GetInfo Response > >4794 10.087860 1.1.1.1 2.2.2.2 Create Response File: > >4796 10.087948 2.2.2.2 1.1.1.1 Find Request File: >SMB2_FIND_ID_BOTH_DIRECTORY_INFO Pattern: *;Find Request File: >SMB2_FIND_ID_BOTH_DIRECTORY_INFO Pattern: * > >4797 10.088101 2.2.2.2 1.1.1.1 Close Request File: >temp\Folder\1 - Copy (83).txt > >4798 10.089075 1.1.1.1 2.2.2.2 Find Response;Find >Response, Error: STATUS_NO_MORE_FILES > >4800 10.089169 2.2.2.2 1.1.1.1 Close Request File: > >4801 10.089291 1.1.1.1 2.2.2.2 Close Response > >4802 10.089375 1.1.1.1 2.2.2.2 Close Response > > > >The initial delay seems to be somewhat random. E.g. but consistenly around >1second per file for the negotiation. > >11686 28.24ms 2.2.2.2 1.1.1.1 Session Setup Request > >11688 28.24ms 2.2.2.2 1.1.1.1 Create Request File: >temp\Folder\1 - Copy (114).txt > >11997 28.74ms 2.2.2.2 1.1.1.1 Create Request File: >temp\Folder\Files > >12079 28.99ms 1.1.1.1 2.2.2.2 Session Setup Response > >12080 28.99ms 2.2.2.2 1.1.1.1 Tree Connect Request >Tree: \\Synology\Share > >Do windows clients connect to \\path\shares differently from >\\ip.ad.d.ress\paths? I?m kind of stuck trying to think of what else to >test to make progress on why the server is so much slower on Windows 10 >clients when mapped over DNS name. Windows reports the smb connection as >a 3.1.1 dialect for both \\ip and \\dns. > >The only intriguing thing I can note is that Windows connects to the \\ip >address as domain\user for credentials. However no matter what I do it >connects as domain*.com*\user for named server connections (both Windows >and Linux\samba). For comparison a Windows 2012R2 file server and a >Windows 10 desktop client follow the correct (fast\streamlined) SMB >transaction with both DNS and IP Address. So it seems to be limited to the >Samba share.That's... really bizarre. The only difference between IP address and dns name should be in the auth used. For IP it's going to be NTLMv2, for DNS it could be krb5.