testing with the files from the iso image: https://bugzilla.samba.org/attachment.cgi?id=9718 tested with 4.12.10 and Windows 10 as client, trying to copy the files using explorer. The copy process hangs always in "get_file.m", which *interestingly* is one if the very few filenames, that exist multiple times in different directories: ./myTempHPF/ScAnVP6.2.1w/vpm/Browser/NewBrowser/get_file.m ./myTempHPF/ScAnVP6.2.1w/vpm/Browser/OldBrowser/get_file.m ./myTempHPF/ScAnVP6.2.1w/vpm/get_file.m Copying those files onto a *Windows* volume works without a problem, also via SMB3. Copying it from there on a Samba share triggers an error. Actually copying the vpm folder alone is enough to trigger the problem. SetInfo SMB2_FILE_ENDOFFILE_INFO comes from the client, the server replyies with a successful response, but then the client is unhappy: Error 0x8007003B: An unexpected network error occurred Something that smbd sends back seems to be bad here.
Can you share a network trace?
Created attachment 16344 [details] sample SMB packet that a Palo Alto deep inspection firewall drops I was trying to make a network sniff using a smbd share on my local machine, where the Windows 10 client is also running. It was not reproducible any more. The error happens if I access a Samba server via VPN though. I thought the latency might make the difference and that might trigger a SMB2/3 client bug in Windows, this is also is what you think of if you read the similar bug #12003 and the related links in that bug report. It seemed like this is not a Samba bug but a Windows client bug that exists since Windows 8.1 and is still around in latest Windows 10 releases. I tried to trigger the "Windows Client VPN bug" by adding artificial latency to my local network interface until I would see the same bug that I saw via VPN. But the bug just didn't pop up. So I remembered that I had some days of fun with a terribly broken SMB connection some weeks ago that, that was cause by an intelligent Palo Alto device, I now did a network capture on the server AND on the client site and compared both of them. Palo Alto strikes again here. It just drops a SMB3 Create Request of the client, that the server never sees, I'll attach the create request packet here.
*** Bug 12003 has been marked as a duplicate of this bug. ***
closing the bug as invalid because it's not a Samba bug. People using SMB should not use broken DPI Firewalls or ask their IT department to disable those broken features.