Slow File Share? Diagnosing SMB Performance on Windows Networks

The file server is up. Ping is fast. But opening a spreadsheet from the share takes thirty seconds, Explorer hangs while listing a folder, and saving a large document crawls. The user blames the network. The network team blames the server. Meanwhile the ticket sits.

SMB performance problems come from a short list of causes: a bad link somewhere in the path, an old SMB dialect being negotiated, signing or encryption overhead, antivirus scanning every read, or slow disks behind the share. Test each one in turn rather than guessing.

Measure it before you change anything

Get a number. A file copy with a stopwatch is fine, but `robocopy` gives you throughput in its summary and is repeatable. Test from the affected PC and from one that is not complaining, and test against a different share on the same server. That tells you whether the problem is one PC, one share, or the server.

Also check which SMB version the connection is actually using. Windows negotiates the best dialect both sides support, but a mismatched policy, an old NAS, or a leftover SMB1 setting can drag it down to a version with no multichannel and no large MTU.

1. Copy a large single file and read the speed: `robocopy \\fs01\share C:\Temp bigfile.iso /NP` and look at the Speed line at the end.
2. Copy a folder with many small files. If large files are fast and small files are slow, latency or antivirus is the issue, not bandwidth.
3. On the client, run `Get-SmbConnection` and read the Dialect column. You want 3.1.1 on modern Windows. Anything below 3.0 deserves a look.
4. Run `Get-SmbClientConfiguration` and check EnableMultiChannel and SigningRequired.
5. Check the link: `Get-NetAdapter | Select Name, LinkSpeed`. A 100 Mbps link on a PC that should be gigabit is a bad cable or a bad switch port, and it is a very common finding.

robocopy \\fs01\share C:\Temp bigfile.iso /NP
Get-SmbConnection | Select ServerName, ShareName, Dialect, NumOpens
Get-NetAdapter | Select Name, Status, LinkSpeed

Check the path: links, duplex and MTU

A single bad patch cable or a switch port stuck at half duplex will make one PC miserable while everyone else is fine. Look at the switch port counters for errors and collisions. On a MikroTik or Ubiquiti switch, the port stats page shows this in a few clicks; on Cisco, `show interface` will list input errors and CRC counts.

If the share is across a VPN or a WAN link, expect it to be slow no matter what you tune. SMB is chatty and each round trip costs a full latency penalty. Consider a DFS replica or a sync tool instead of a remote share.

• Replace the patch cable and move the PC to a different switch port. Cheap and often decisive.
• Check the server's NIC as well. A file server on a single 1 Gbps link with many users is saturated at busy times, and Task Manager on the server will show it.
• Confirm jumbo frames are either on end to end or off everywhere. A mismatch causes fragmentation and retransmits.

Test-NetConnection fs01 -Port 445 -TraceRoute
Get-NetAdapterAdvancedProperty -Name Ethernet | Where DisplayName -like "*Jumbo*"

Antivirus, signing and encryption

Endpoint protection on the client scans files as they are read from the share, and protection on the server scans them as they are served. Two scans per open, and the small-file workloads suffer most. Check the vendor's guidance for file server exclusions and apply them on the server; on the client, exclude the share path only if the vendor supports it and the security team agrees.

SMB signing and encryption add CPU overhead on both ends. On a modern CPU the cost is modest, but on an older NAS or a server with a weak CPU it is noticeable. Do not disable signing to gain speed; it protects against relay attacks. Instead, make sure the server has the CPU to handle it and that the client is using SMB 3.x, where signing is far cheaper than in older dialects.

Get-SmbServerConfiguration | Select RequireSecuritySignature, EncryptData, EnableSMB1Protocol
Get-SmbShare | Select Name, EncryptData

Look at the disks behind the share

When every client is slow and the network is clean, the server's storage is the bottleneck. Open Resource Monitor on the server, go to the Disk tab and watch Disk Queue Length and Response Time on the volume hosting the share. A response time consistently above 20 ms under load means the disks cannot keep up. A single volume hosting the shares, the OS and a backup target is a common design mistake on small servers.

Also check whether a backup job, a full antivirus scan or a deduplication job is running during business hours. On a virtual file server, look at the datastore latency on the hypervisor, since a noisy neighbour VM on the same storage will slow the share even when the file server itself looks idle.

1. On the server, run `Get-Counter '\PhysicalDisk(*)\Avg. Disk sec/Read'` and `'\PhysicalDisk(*)\Avg. Disk sec/Write'` during the slow period.
2. Check `Get-ScheduledTask` and the backup software for jobs overlapping business hours.
3. On a RAID controller, confirm the battery or flash-backed cache is healthy. A controller that fell back to write-through mode because of a dead cache battery will feel like a network problem.
4. If the volume is on spinning disks, plan a move to SSD. Small-file workloads are seek-bound, and no network tuning will fix that.

Get-Counter '\PhysicalDisk(*)\Avg. Disk sec/Read','\PhysicalDisk(*)\Current Disk Queue Length' -SampleInterval 2 -MaxSamples 10

Frequently asked questions

Takeaway

Slow file shares are rarely mysteries once you measure. Get a throughput number, confirm the SMB dialect and link speed, then walk the path from cable to switch to server NIC to disk. Antivirus and signing are real costs but not reasons to weaken security. If the storage is the bottleneck, plan a fix rather than tuning around it.