Slow SMB File Transfer? Here's How to Fix It Properly

Introduction

#

You start copying a 300 GB VM disk to a Windows file share. File Explorer shows 110 MB/s for the first few seconds, then the number collapses to 8 MB/s and stays there. Or you copy a folder with 40,000 small source files and watch it crawl at 900 KB/s for an entire afternoon.

Neither problem is mysterious. SMB, the protocol behind Windows file sharing, is sensitive to how the copy is made, how the storage behaves, and what the CPU is doing. Once you know which of those is the bottleneck, the fix is usually a single flag or a single setting.

This guide walks through the checks in the order that saves the most time. It is based on Microsoft’s own troubleshooting guidance, with the parts that actually matter in practice pulled to the front.

Symptom → first thing to try

#

1. The copy tool matters more than you think

#

File Explorer performs single-threaded copies with buffered I/O. It is fine for moving a few documents. It is the wrong tool for a bulk transfer.

robocopy was built for exactly this job: it is multi-threaded, can bypass buffering, and can write its output to a log instead of redrawing the console for every file.

For a single large file, use unbuffered I/O with /J:

robocopy "D:\ISOs" "\\fileserver\share\ISOs" *.iso /J /R:1 /W:1 /LOG:"C:\logs\robocopy-iso.log"

For a large number of small files, use multithreading with /MT:

robocopy "D:\Projects" "\\fileserver\share\Projects" /E /MT:16 /LOG:"C:\logs\robocopy-small.log"

A few notes on those flags:

• /J is for unbuffered I/O. It helps with files larger than about 1 GB.
• /MT:16 copies 16 files at once. The default is 8 and the maximum is 128.
• /LOG matters. Writing progress to the console is slow, and on a small-file job it can eat a noticeable slice of your transfer time.
• Do not go straight to /MT:128. More threads is not automatically faster. Two threads per CPU core is a safe starting point, then test.

2. Small files are a different problem

#

This is the part most guides skip. Copying 50,000 files under 1 MB is not a bandwidth problem; it is a file creation problem.

For every file, SMB issues a create command, the file system does work, the data is written, and the file is closed. That round trip crosses the network, the SMB stack, the file system, and often your antivirus filter driver. With a single-threaded tool, the link sits idle while each file is being created.

That is why throughput can fall below 1 MB/s even on a healthy gigabit network.

Multithreading fixes it by overlapping the waiting: while one or two files are being created, data for other files is already in flight. Hence /MT.

If a job is still slow with /MT, three options usually help:

1. Archive first, copy once. Zip or 7-Zip the folder, copy the single archive, then extract it locally on the destination. Do not extract over SMB, because that recreates the small-file problem.
2. Use AzCopy when the destination is Azure Storage; it has built-in concurrency and cloud-specific tuning.
3. Use a trusted multi-threaded copy tool if you already have one. Just measure before and after rather than assuming it is faster.

3. Enable SMB compression, but only where it pays

#

SMB compression compresses data on the fly during the transfer. It costs a little CPU and saves bandwidth and time. On a 1 Gbps link or Wi-Fi, that trade is usually worth it.

It shines on files with lots of empty or repetitive space:

• Virtual machine disks (.vhd, .vhdx, .vmdk, .ovf)
• .iso images
• .dmp crash dumps

It does not help much with data that is already compressed:

• Archives (.zip, .7z, .rar)
• Video (.mp4, .mkv)
• Audio (.mp3, .flac)

SMB compression is available starting with Windows 11 and Windows Server 2022. You can enable it per share:

Set-SmbShare -Name "Backups" -CompressData $true

Request it for a mapped drive:

New-SmbMapping -LocalPath "Z:" -RemotePath "\\fileserver\Backups" -CompressNetworkTraffic $true

Or ask for it on a single robocopy job:

robocopy "C:\VMs" "\\fileserver\Backups\VMs" *.vhdx /COMPRESS

One caveat: SMB compression does not work with SMB Direct over RDMA. If you are on RDMA hardware, compression is skipped by design.

4. Storage is usually the real ceiling

#

It is easy to blame the network. In practice, the storage underneath the share often runs out of sustained write speed first.

Microsoft’s rough real-world numbers for SMB, assuming no CPU, memory, or network errors:

Read that table carefully. Those are sustained numbers. Most drives advertise peak performance, and peak is often several times higher than what the drive can hold for a long copy.

If your 10 Gbps link only ever reaches 300 MB/s, the link may be fine; the array behind it may not be.

For very high throughput without roasting the CPU, look at SMB Direct (SMB over RDMA). It moves data with far less CPU involvement, which is often the difference between “fast” and “fast and stable”.

5. “It starts fast, then slows down”

#

This is a classic cache cliff.

The first part of a copy is absorbed by storage cache and system memory. When those buffers fill, Windows switches to write-through and the rate drops to what the underlying media can sustain.

To confirm it, open RAMMap from Sysinternals and watch the Mapped File value. If it stops growing, the memory buffer is exhausted. RAMMap does not refresh by itself, so press F5.

Then compare storage counters against network throughput. If storage performance drops at the same moment the copy speed drops, you have your answer.

On Windows Server 2016 and later, there is another pattern: performance degrading roughly every 5 GB. That points at the remote file dirty page threshold, which is tunable in the cache and memory management settings.

6. Check the network, but check the right things

#

Network problems are real, but the fixes are narrower than folklore suggests.

• Look for packet loss. TCP reacts to loss by throttling itself. A link that “works” can still be silently dropping frames.

• Do not disable network offloads. RSS, LSO, RSC, and TCP/UDP checksum offload exist to raise throughput and lower CPU use. Disabling them usually makes things worse.

• Check SMB Multichannel. On SMB3, multiple network paths can be used at once. Verify it is active:

  Get-SmbMultichannelConnection

• Check client limits. Make sure large MTU is enabled and bandwidth throttling is off:

  Set-SmbClientConfiguration -EnableBandwidthThrottling 0 -EnableLargeMtu 1

If the client is CPU-bound during a fast transfer, the network is not your bottleneck. The SMB stack is.

7. SMB signing and encryption have a cost

#

SMB signing and SMB encryption are known to reduce transfer speed. How much depends on the hardware: core count, core speed, and how much CPU time is left after everything else.

Starting with Windows 11 version 24H2 and Windows Server 2025, SMB signing is required by default. Microsoft explicitly recommends against turning it off, because signing protects against spoofing, tampering, and relay attacks.

8. Antivirus can be a hidden tax

#

Endpoint protection scans network traffic and file system operations. For one large file, that overhead is mostly paid once. For 30,000 small files, it is paid 30,000 times.

To measure it, temporarily test a copy with file scanning disabled and the filter drivers unloaded. If the speed jumps, you have found a big part of the problem. Then work with your security team on exclusions for the file server role rather than a blanket “turn off antivirus”.

9. Office documents open slowly? That’s leasing

#

If raw file copies are fine but Excel workbooks crawl when opened from a share, especially over a WAN, the problem is probably SMB leasing, not bandwidth.

Test by disabling leasing on the server:

Set-SmbServerConfiguration -EnableLeasing $false

On Windows Server 2019 and later, you can do it per share:

Set-SmbShare -Name "Finance" -LeasingMode Shared

If you control the destination, another option is to replicate the file to a local file server so Office opens it over the LAN instead of the WAN.

10. When slow is expected

#

Some workloads are slow on purpose.

Backups, databases, and Scale-Out File Server (SOFS) deployments often require write-through, which bypasses every cache and commits data directly to the storage medium. If the storage has weak write-through performance, SMB will be slow no matter what you tune.

In that case, the fix is storage, not SMB.

Conclusion

#

Work through it in this order:

1. Copy tool: robocopy instead of File Explorer.
2. File pattern: /J for big files, /MT for many small ones.
3. Compression: enable it when the data is compressible.
4. Storage: confirm sustained throughput, not peak.
5. Network: check loss, multichannel, MTU, and offloads.
6. Security software: measure the antivirus tax.

Most “slow SMB” cases are solved in the first two steps. The rest are there for the cases that are not.

If you have a stubborn one, post your robocopy command, file sizes, link speed, and storage type in the comments; that combination usually makes the bottleneck obvious.

References

#

• Slow SMB files transfer speed (Microsoft Learn)
• SMB compression (Microsoft Learn)
• robocopy reference (Microsoft Learn)
• Performance tuning for SMB file servers (Microsoft Learn)