NAS Slow Transfer Speeds: A Diagnosis Order

“The NAS is slow” is not a diagnosis. It is a symptom with at least six common causes, and they sit at different layers. Working through them in the wrong order is how people end up buying a 10 gigabit card for a machine whose actual problem is a shingled drive or a duplex mismatch on a damaged cable.

The order below goes from cheapest check to most expensive, and each step either eliminates a layer or points at it.

Step 1: work out the ceiling before calling anything slow

Every transfer is capped by the slowest link in the chain, and the arithmetic is fixed.

Link	Raw bits per second	Raw MB/s	Realistic file throughput
100BASE-TX	100 Mb/s	12.5	~11 MB/s
1000BASE-T	1000 Mb/s	125	~113 MB/s
2.5GBASE-T	2500 Mb/s	312	~280 MB/s
10GBASE-T	10,000 Mb/s	1250	~1100 MB/s
Wi-Fi 5, 80 MHz, 2 streams	~867 Mb/s nominal	108	Highly variable, frequently under 40 MB/s

The realistic column accounts for Ethernet, IP and TCP framing overhead plus protocol chatter. A gigabit-connected NAS delivering 110 MB/s is not slow. It is finished. If the number you are unhappy with is close to the ceiling for the link you have, the rest of this article will not help and the answer is a faster link.

Note what is not in the table: the drives. Western Digital’s WD Red Plus brief quotes internal transfer rates of 180 MB/s on the 2 TB and 4 TB models up to 260 MB/s on the 12 TB WD120EFGX, which means a single modern NAS drive already outruns gigabit Ethernet on its own. Adding drives does not make a gigabit link faster. If the array is the thing you upgraded, the link is the thing you did not.

Step 2: confirm the negotiated link speed at both ends

Autonegotiation is supposed to be invisible, and usually is. When it is not, the failure is silent and dramatic: a damaged cable, a bent pin or a marginal connector can drop a gigabit link to 100 Mb/s, and everything keeps working at one tenth of the speed. This costs more people more time than every other cause combined.

Check the negotiated speed on the NAS, on the client and on the switch port, not just on one of them. Every managed switch reports per-port speed and duplex. Most NAS operating systems show link speed in their network settings page. On Linux, ethtool <interface> reports it; on Windows, the adapter status dialog does.

If a port has negotiated 100 Mb/s, replace the cable before doing anything else, then re-check. Cables fail in ways that pass a visual inspection.

Step 3: split the network from the disk

Until you know which side is slow, everything else is guesswork. Two independent tests separate them.

For the network alone, run iperf3 in server mode on the NAS and client mode on the workstation. It moves generated traffic with no disk involvement, so the result is the network path and nothing else. A gigabit path should report somewhere near 940 Mb/s.

For the disk alone, generate a large file locally on the NAS and write it to the array without crossing the network, using dd with a large block size or the platform’s own equivalent. This puts a number on the array itself.

The outcome tells you where to look next. Fast on the network and slow on disk means the array is the problem, and steps 5 and 6 apply. Slow on the network and fast on disk means the fault is cabling, negotiation, or the client. Slow on both means look for something systemic, such as a CPU saturated by encryption.

Step 4: rule out protocol behaviour

Once the raw path is proven, the file-sharing protocol is the next layer.

Single-stream limits. SMB moves a single file over a single connection unless something enables otherwise. Microsoft’s SMB Multichannel establishes multiple connections per session when the client and server both present multiple network paths or RSS-capable adapters, which is what lets a single transfer use more than one link. Without it, aggregate bandwidth on the machine and single-transfer bandwidth are different numbers.

Link aggregation misunderstood. Bonding two gigabit ports does not make one file transfer faster. Synology’s knowledge base puts it directly: total network bandwidth “will only increase if there are multiple clients”, and each client is answered by one of the bonded interfaces. The mechanism underneath is that a flow is hashed onto a single physical member and stays there. Two clients can each get a gigabit; one client cannot get two.

Small files. A directory of 50,000 small files is a different workload from one 50 GB file. Per-file overhead, metadata operations and round trips dominate, and throughput measured in MB/s collapses while the machine is working perfectly. Compare like with like: test with a single large file before concluding anything.

Signing and encryption. SMB signing and SMB encryption both cost CPU. On a low-power appliance processor that cost can become the bottleneck. Samba exposes these as configurable options in smb.conf, and the manual page documents their behaviour. Turn them off only where the network genuinely warrants it, since they exist for a reason.

Step 5: look at the array, not the network

If step 3 showed the disk side is slow, the usual suspects are in a short list.

Parity write penalty. Every write to a single- or double-parity array requires recalculating and writing parity. Small random writes suffer far more than large sequential ones. A mirror does not pay this cost, which is why mirrored layouts are preferred for virtual machine and database storage.

A rebuild or scrub in progress. A resilver, rebuild, or scheduled scrub consumes array bandwidth for hours or days. Check for one before investigating anything else, because the answer may simply be to wait.

Shingled drives. A drive-managed SMR disk runs at full speed until its persistent cache fills, then falls to its shingled rewrite rate. The symptom is characteristic: a large transfer starts fast and then drops sharply partway through, and does not recover until the machine goes idle. If a transfer graph has a cliff in it rather than a flat line, read CMR vs SMR NAS drives and check the model numbers.

A nearly full pool. Copy-on-write filesystems slow markedly as free space runs out, because allocation has to work harder to find contiguous space. Sustained operation above roughly 80 percent occupancy is where this typically becomes noticeable.

Insufficient memory. Cache is what absorbs bursts. A machine with 1 or 2 GB of fixed memory has almost none of it, which shows up as inconsistent throughput under mixed load rather than a flat slow number.

Step 6: check the client

The NAS is frequently innocent. A client on Wi-Fi is capped by radio conditions and shared airtime, and no NAS-side change will alter that. Real-time antivirus scanning inspects every file as it is written and can halve throughput. A client writing to a slow local disk cannot receive faster than that disk accepts. And a laptop on battery may be running its CPU and network adapter in a power-saving state.

Test from a second, wired client before making any hardware decision. If the second client is fast, the problem was never the NAS.

Symptom to cause, at a glance

Symptom	Most likely cause	First check
Steady ~11 MB/s	Link negotiated at 100 Mb/s	Port speed on switch and both endpoints
Steady ~110 MB/s	Gigabit ceiling reached, nothing is wrong	Link arithmetic in step 1
Fast then a sudden cliff	SMR write cache exhausted	Drive model numbers against the datasheet
Slow only for many small files	Per-file protocol overhead	Repeat with one large file
Slow from one client only	Client-side: Wi-Fi, antivirus, local disk	Test from a second wired client
Slow for everything, all the time	Rebuild or scrub running, or pool nearly full	Array status and free space
Aggregation added, single transfer unchanged	Expected behaviour of link bonding	Synology aggregation documentation

When faster networking is genuinely the answer

Upgrade the link when, and only when, the array demonstrably outruns it. A four-drive array reading sequentially will exceed gigabit comfortably, so if step 3 showed several hundred MB/s on the disk side and 113 MB/s over the wire, the network is the constraint and replacing it will help.

The realistic options are 2.5GBASE-T, which often works over existing cabling and is now common on consumer switches, and 10GBASE-T, which needs a card at both ends and a switch that supports it. For a build with a spare PCIe slot, the Intel X550-T2 is a dual-port 10GBASE-T adapter with mature driver support across the operating systems used for storage, which matters more than raw specification when the card has to be recognised by a NAS distribution rather than a desktop OS.

Before ordering anything, confirm the slot. A 10 gigabit card needs both physical space and electrical lanes, and lane allocation on consumer boards is easy to get wrong; sizing NAS hardware covers how those budgets are spent, and the drive bay and PCIe lane sizer will put a number on what a given build has left. If the machine is an appliance with a soldered gigabit port and no expansion slot, the honest answer is that the upgrade is a new machine, and the NAS buying guide is the place to start that decision.

Work the list in order. Most slow NAS complaints resolve at step 2 or step 4, both of which are free.