[Samba] Windows clients connecting to SMB share differently over IP than DNS
Jeremy Allison
jra at samba.org
Thu Apr 1 16:50:12 UTC 2021
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.
More information about the samba
mailing list