Why Your NAS File Copy Is Slow — and How to Diagnose It Step by Step
A NAS file copy that crawls along at a few megabytes per second is one of the most common — and most fixable — home-network frustrations. The cause is almost always a single weak link: a Wi-Fi hop, a slow drive, a pile of tiny files, or a cable that quietly negotiated down. This guide is an ordered diagnostic: work through it top to bottom and you'll isolate the bottleneck instead of guessing.
Start by knowing what "slow" should look like
Before diagnosing, set expectations. A gigabit link tops out around 110–118 MB/s for large files. A single hard drive sustains maybe 150–250 MB/s on big sequential copies but far less on many small files. Wi-Fi is variable and usually delivers a fraction of its headline rate. So "slow" depends on the file: a large video crawling at 20 MB/s over a wired gigabit link is clearly wrong, while a folder of thousands of tiny files copying slowly may be completely normal protocol behavior. Keep that distinction in mind as you go.
Tip: Test with two different payloads every time — one big file (say 5 GB or larger) and one folder of many small files. The gap between them is itself a clue, pointing at protocol overhead rather than raw link speed.
The ordered checklist
- Confirm the negotiated link speed at both ends. This is the number-one culprit and takes ten seconds. On Windows, open the network adapter status; on macOS, System Settings > Network > Details; on the NAS, its control panel. If you expect gigabit and see 100 Mbps, you've found it — a bad cable or port negotiated down. A 100 Mbps link caps you at about 11–12 MB/s no matter what.
- Test wired vs Wi-Fi. If either the client or the NAS is on Wi-Fi, that is your prime suspect. Temporarily plug the client into the same switch as the NAS with a known-good cable and retest. If speed jumps, Wi-Fi was the limit — see Ethernet vs Wi-Fi speed for why, and router placement and channels if you must stay wireless.
- Run a LAN speed test to separate network from disk. A memory-to-memory test measures the network path with the disks out of the picture. If it hits your link ceiling but real file copies don't, the storage — not the network — is the bottleneck. Our test your local network speed guide covers how, and a tool such as a LAN speed test like PulseLAN does exactly this.
- Check disk speed on both ends. A copy is limited by the slowest disk it touches. An old 5400-rpm drive, a nearly full drive, or especially a USB-attached drive on the NAS or client can be the ceiling. Copy a large file locally on each machine (not over the network) to see how fast its storage really is.
- Compare small-files vs large-files. If large files fly and small files crawl, that's protocol overhead, and it's expected. There's no "fix" beyond zipping many small files into one archive before transferring.
- Rule out background interference. Antivirus real-time scanning, file indexing (Windows Search, Spotlight), and cloud-sync clients all inspect files mid-copy and can gut throughput. Temporarily pause them and retest.
- Inspect the physical layer. A marginal cable, a dirty jack, or a duplex mismatch can cause slow speeds and errors. Swap the cable, try a different switch port, and check the switch/NIC for a half-duplex or error-counting condition.
Digging into the likely causes
Link speed and cabling faults
A port that negotiates to 100 Mbps instead of 1000 is the classic silent failure, usually from a damaged or sub-spec cable, a bent pin, or a flaky port. A duplex mismatch — one side half-duplex, the other full — produces slow transfers plus rising error counts. Swapping the cable and trying another port resolves most of these in minutes. If you're on multi-gig and seeing only gigabit numbers, the same logic applies at a higher tier; the ISP or home network bottleneck guide helps confirm the problem is local.
Disk speed on either end
People assume the network is slow when the disk is the real limit. A single spinning drive that's nearly full, fragmented, or simply old may only manage 40–60 MB/s on real workloads, and a USB 2.0-attached drive is far worse. RAID rebuilds and parity writes also slow a NAS temporarily. Always benchmark each machine's local disk before blaming the wire — if the source or destination drive can't read or write faster than the transfer speed, the network was never the problem. Our home NAS setup and speed guide covers matching storage to the network.
Small files and protocol overhead
Every file in a copy involves setup and teardown round-trips with the server. For a 10 GB movie that overhead is invisible; for 100,000 tiny files it dominates, and the transfer rate can drop by an order of magnitude even on a perfect network. This is inherent to how file protocols work, not a fault to fix. Archiving small files into a single .zip or .tar before transferring sidesteps it entirely.
SMB, AFP, and NFS differences
The sharing protocol matters. SMB is the default on Windows and modern macOS and performs well when using SMB3 — but the ancient SMB1 is slow and insecure, so make sure it's disabled and both ends negotiate SMB3. AFP is Apple-legacy and deprecated; prefer SMB on current macOS. NFS is common in Linux and virtualization setups and can be faster for some workloads but needs careful configuration. If a Mac talks to a NAS over AFP and drags, switching the mount to SMB often helps.
Background scanners and indexers
Real-time antivirus is the sneakiest cause of slow many-file copies: the scanner inspects each file as it lands, adding latency to every one. Indexing services and cloud-sync agents do the same. Pausing them for a test copy quickly proves whether they're responsible.
Symptom → cause → fix
| Symptom | Likely cause | Fix |
|---|---|---|
| Capped near 11–12 MB/s | Link negotiated to 100 Mbps | Swap cable, try another port, check link speed |
| Wireless slow, wired fine | Wi-Fi is the limiting hop | Use Ethernet or improve Wi-Fi placement/band |
| Large files fine, small files crawl | Protocol overhead per file | Zip/archive small files before copying (expected behavior) |
| All transfers slower than link ceiling | Slow disk on one end | Benchmark local disk; replace/defrag or move off USB |
| Speed drops mid-copy, CPU busy | Antivirus/indexing/sync scanning files | Pause scanners and retest |
| Slow + rising error counts | Duplex mismatch or bad cable | Fix auto-negotiation, replace cable |
| Mac-to-NAS slow specifically | Legacy AFP mount | Reconnect the share over SMB3 |
| Intermittent stalls, retries | Packet loss on the path | See the packet-loss diagnostic below |
Note: If transfers stall, retry, or drop entirely rather than just running slow, suspect packet loss rather than a speed cap. Our diagnose packet loss guide walks through finding a flaky cable, port, or overloaded link.
Putting it together
The discipline that makes this work is changing one variable at a time and re-measuring. Confirm the link speed first because it's the fastest check and the most common problem. Then separate network from disk with a LAN speed test, because that single step tells you which half of the system to investigate. From there the checklist narrows quickly: Wi-Fi, a slow drive, tiny files, a background scanner, or a cable fault covers the large majority of real cases.
A slow NAS copy almost never has a mysterious cause — it has an unmeasured one. Walk the checklist in order, test with both large and small files, and let the numbers point at the weak link. Once you've found it, the fix is usually cheap and quick, and your transfers will finally run at the speed your hardware was always capable of.