Bug 12003 - SMB 2 / 3 triggering Windows Error 0x8007003b while transfering larger files over slow connections
Summary: SMB 2 / 3 triggering Windows Error 0x8007003b while transfering larger files ...
Status: RESOLVED DUPLICATE of bug 14577
Alias: None
Product: Samba 4.1 and newer
Classification: Unclassified
Component: File services (show other bugs)
Version: 4.4.4
Hardware: x64 Windows 2012 R2
: P5 critical (vote)
Target Milestone: ---
Assignee: Samba QA Contact
QA Contact: Samba QA Contact
Depends on:
Reported: 2016-07-01 09:47 UTC by Ruben Kelevra (dead mail address)
Modified: 2020-11-17 23:19 UTC (History)
6 users (show)

See Also:

log.samba.gz (595.08 KB, application/gzip)
2018-01-11 15:41 UTC, Felix Botner
no flags Details
log.smbd.gz (313.17 KB, application/gzip)
2018-01-11 15:42 UTC, Felix Botner
no flags Details
net.pcapng (3.33 MB, application/x-pcapng)
2018-01-11 15:42 UTC, Felix Botner
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Ruben Kelevra (dead mail address) 2016-07-01 09:47:43 UTC
Dear devs,

currently there seem to be a bug on newer SMB-clients, like Windows 10 or Windows Server 2012 R2, while receiving files from a smbd-server which runs at default config.

So on the network-side the Windows client tend to send a TCP RST while transferring. The Windows client shows up the error 0x8007003b. Else the transfer-window stalls for several seconds and bumps up the progress for several percents.

If the server capabilitys are reduced to "NT1" ("server max protocol") the issue disappears.
Comment 1 Jeremy Allison 2016-07-01 17:42:32 UTC
Are you sure this is a Samba bug ? See here:


for the same error seen in a Windows -> Windows environment.
Comment 2 Ruben Kelevra (dead mail address) 2016-07-02 12:25:31 UTC
Actually I'm pretty sure. We've replaced the thin client which was running the smbd with a windows 10 to access the domains dfs system with it, and the copy with of the same data over the same connection work fluently and very reliable.

We also tried to copy the same data from the samba server and this work as well.

So these ones work:

S2003 ---> smbd (default config)

2012r2 <--- win10

2012r2 ---> smbd (with maxp nt1)

This one not:

2012r2 ---> smbd (default config)
Comment 3 (dead mail address) 2016-07-18 19:38:38 UTC
I am also affected, I have problems with Windows 8/8.1/10 workstations trying to send "big" files (more than 5MiB) to my samba server, disabling 2.0/3.0 dialect in Windows solves the issue. It tends to happen over low performance links like 500kbps-5000kbps. Can somebody confirm where the issue is?
Comment 4 (dead mail address) 2016-07-18 19:40:10 UTC
Sorry for double post, there is very good description:


I've exactly the same symptoms.
Comment 5 Klaus J 2017-02-11 20:48:31 UTC
Same problem using Cisco AnyConnect VPN and ~0,6 Mbps upload speed.

My test results:

Client  -> Server (upload)

Windows 7/10 -> Windows Srv 2012R2 : OK
Windows 7/10 -> Samba version 4.3.11-Ubuntu : error 0x8007003b
Mac OS X -> Samba version 4.3.11-Ubuntu : OK
Comment 6 Felix Botner 2018-01-11 15:41:06 UTC
Same here, i can reproduce this problem with the following setup

* Windows 8.1 client (KVM) with reduced interface bandwidth 
   <interface type='bridge'>
       <inbound average='54'/>
       <outbound average='54'/>

* Linux with samba 4.6.1-1 and a "standard" config.

When trying to copy a "large" file (30MB) from the server to the client, the client fails with Error 0x8007003b. I can see the TCP RST form the client in the network trace.
Copying a 3MB file works, though.

Workaround for me was

  Set-SmbClientConfiguration -SessionTimeout 600

on the windows machine, but i am not sure what implications this has.

Attached are the log.samba log.smbd (level 99) and the tcp dump from the failed file copy operation (name of the test file was mytestfile.txt).
Comment 7 Felix Botner 2018-01-11 15:41:43 UTC
Created attachment 13898 [details]
Comment 8 Felix Botner 2018-01-11 15:42:00 UTC
Created attachment 13899 [details]
Comment 9 Felix Botner 2018-01-11 15:42:15 UTC
Created attachment 13900 [details]
Comment 10 Björn Jacke 2020-11-17 23:19:44 UTC

*** This bug has been marked as a duplicate of bug 14577 ***