Diagnosing slow NAS performance: an editor's checklist

When a NAS feels slow for editing, the cause is almost never the one thing you suspect first. I have chased "the drives are too slow" only to find a 2.5 GbE port negotiating at 1 Gb, and I have replaced a switch that turned out to be fine while the real culprit was SMB signing eating two thirds of the throughput. So work the problem like a flight checklist, in order, from the wire up to the application. Each layer has a cheap test. This guide walks you down the stack: link, protocol, drives, cache, and client. Run the test, write down the number, then move on. The bottleneck is whichever layer caps lowest.

Decide what "fast enough" actually means #

Before you measure anything, set the bar. Editing is not one big copy. It is many small reads as the playhead scrubs, plus the steady draw of playing back a timeline. The steady number is set by your codec. Apple's published target data rate for ProRes 422 HQ at UHD (3840x2160) and 29.97 fps is 737 Mbps, which is about 92 MB/s for a single stream. Plain ProRes 422 is 492 Mbps (about 62 MB/s), and ProRes 4444 climbs to 1106 Mbps, roughly 138 MB/s (Apple ProRes specs, checked Jun 2026). A two-layer multicam at HQ wants two of those streams at once, so call it 180-200 MB/s sustained with headroom.

The analogy I use: codec data rate is the speed limit you must hold the whole drive home, and scrubbing is the stop-and-go traffic that punishes anything with slow reflexes. A link that benchmarks at a gorgeous sequential number can still stutter if it cannot answer thousands of tiny requests quickly. Write your target down in MB/s. Everything below either clears it or does not.

Layer 1: the link, and is it the speed you think #

Start at the wire because it is the most common lie. A port labeled 10 GbE that quietly fell back to 1 GbE caps you at about 110 MB/s no matter how good the rest of the chain is, and nothing downstream can rescue it. On macOS, hold Option and click the Wi-Fi or Ethernet menu, or open System Settings and check the negotiated link rate. On the NAS side, the admin UI shows the actual negotiated speed per port. Confirm both ends, plus every switch hop between them, report the same number.

Bad or borderline cabling is the usual reason a 10 GbE link trains down. Cat5e can carry 10 GbE only over short, clean runs; for anything past a couple of meters you want Cat6 or Cat6a. If a link flaps or renegotiates, swap the cable before you swap anything expensive. One more macOS-specific trap: Apple's networking stack caps the client MTU at 1500, so jumbo frames (MTU 9000) only help when both NAS and switch run them and your clients are not Macs. On a Windows or Linux client, enabling jumbo frames can lift a 10 GbE link from roughly 6.5-7 Gbps to 9.8-9.9 Gbps (community testing, checked Jun 2026); on a Mac you will not get that lever.

If your slowness is really a link problem, our notes on Thunderbolt versus 10 GbE and 10 GbE on a budget cover what to buy. And if the link is fine on a cable but miserable on Wi-Fi, see Wi-Fi versus wired for editing before you blame the NAS.

Layer 2: the protocol, where macOS quietly taxes you #

This is the layer that surprises people, because the hardware is innocent and the software is throttling you. SMB is the protocol almost every NAS speaks to a Mac, and on macOS it has two well-documented drags: packet signing and single-channel behavior.

SMB signing has been on by default since macOS 10.11.5, and it costs real throughput because every packet gets cryptographically signed. The reports are not subtle: editors have measured transfers stuck around 20 MB/s in bursts that jumped to a sustained 80-100 MB/s once signing was disabled on the connection (community fixes, checked Jun 2026). You can check whether it is active with smbutil statshares -a in Terminal and look for SIGNING_ON. Disabling it trades a measure of integrity protection for speed, so it is a choice for a trusted local network, not the open internet.

The second drag is multichannel. macOS has shipped SMB Multichannel since Big Sur 11.3, but its client implementation has been flaky for years: editors on 100 GbE hardware have reported macOS opening only a single TCP socket to the server on port 445 and topping out near 3 GB/s while Windows saturates the same link (TrueNAS and Apple developer forum reports, checked Jun 2026). Multichannel also only bonds ports of the same speed and type, and pairs down to the slower side, so a 2.5 GbE client plus a 10 GbE NAS bonds at 5 Gbps at best. If your sequential copy is healthy but editing stutters, the protocol is often where the round-trip latency hides. We dig into that round-trip problem specifically for remote setups in why your NAS feels slow over a VPN.

Layer 3: the drives, sequential is not the whole story #

Now test the storage itself, and test it the way editing actually hits it. A modern 7200 rpm NAS drive does roughly 180-230 MB/s sequential on the outer tracks, with the densest models nudging 250 MB/s (drive vendor and community data, checked Jun 2026). Stripe several across RAID and the sequential numbers look heroic. That is what Blackmagic Disk Speed Test measures, and it is the number people quote when they say their array is plenty fast.

The trap is that scrubbing a timeline is not sequential. It is small, scattered, random reads, and spinning disks pay a seek penalty on every one. This is why I run AmorphousDiskMark instead of, or alongside, Blackmagic: it reports random 4K performance, not just the friendly sequential figure. A RAID of hard drives can post 1500 MB/s sequential and still hitch on a multicam timeline because the random read column is a fraction of that. The mental model: sequential speed is how fast a librarian walks one full aisle; random speed is how fast they sprint between forty different shelves. Editing is the sprint.

Two checks here. First, mismatched drives: striping a 5400 rpm disk into an array of 7200 rpm disks drags the whole stripe to the slow member, because RAID 0, 5, and 10 wait for every participating drive on each read or write. Second, a nearly full array fragments and slows down, especially on copy-on-write filesystems. If the drives are your floor, the SSD-versus-HDD math in HDD vs SSD vs hybrid for media libraries and the deeper ZFS for video editors primer are the next reads.

Layer 4: the cache, or why warm beats cold #

If layers 1 through 3 all clear your target and editing still feels grudging, the issue is usually that every read is making the full round trip to cold storage. A cache fixes this by keeping the bytes you touch most on fast local media. The diagnostic question is simple: does the second pass over the same footage feel faster than the first? If yes, something is caching and you want more of it. If no, you have no effective cache and every scrub pays the full latency every time.

There are two flavors. A NAS-side read cache (an SSD tier or large RAM cache in TrueNAS, Synology, or QNAP) helps everyone on the network but still sends bytes across the wire. A client-side cache keeps hot blocks on the editor's own SSD, so a re-read never touches the network at all. The size you need is driven by how much footage is live at once: scratch and current selects, not the whole archive. Our piece on sizing your SSD cache works through that number with examples.

This is one of the two places JuiceMount is genuinely native to the topic, so I will say it plainly and once: JuiceMount mounts the NAS as a real Finder volume and keeps a local SSD block cache, so a warmed timeline reads at local-SSD speed instead of network speed. Where it does not fit: it cannot make a 1 GbE link faster on the first, cold read, and it will not rescue an array whose random reads are too slow to fill the cache in the first place. Cache is the layer that hides a slow network, not a broken one.

Layer 5: the client and the app, the last mile #

Save the editor's machine for last, because it is the easiest to blame and the hardest to measure cleanly. The usual offenders are real, though. Spotlight indexing a freshly mounted NAS volume will hammer it with reads for hours; add the share to Privacy and Security, Spotlight, and Search Privacy to exclude it while you work. Antivirus and backup agents scanning network volumes do the same. And the NLE itself has settings that matter: in Premiere and Resolve, point the media cache and scratch at a fast local SSD, never at the NAS, or you turn every preview render into network traffic.

The clean test for this layer is comparison. Mount the same share on a second machine and run your codec-target copy. If the second machine is fast and the first is slow, the problem is local: indexing, an agent, a tired NIC driver, or a misconfigured cache path. If both are equally slow, you have already found the real bottleneck upstream and the client is innocent. When the network truly is the floor and no client tweak helps, the deeper structural fix is a different access model, which is the territory of block-level streaming versus whole-file sync.

The checklist, in order #

Run these top to bottom and stop at the first one that fails your codec target. Whichever layer caps lowest is your bottleneck; fixing anything above it changes nothing.

1. Link: confirm every hop negotiated the speed you paid for. Swap suspect cables before hardware.
2. Protocol: on macOS, check SMB signing with smbutil statshares -a and watch for single-channel behavior. Round-trip latency lives here.
3. Drives: test random 4K with AmorphousDiskMark, not just sequential. Look for mismatched or nearly full arrays.
4. Cache: does a second pass beat the first? If not, you have no effective cache.
5. Client: exclude the share from Spotlight and AV, move NLE media cache to local SSD, then compare against a second machine.

If you have worked all five and the floor is still the network itself, that is a design problem, not a tuning problem, and it is worth comparing appliances and access models rather than chasing settings. Start with the best storage appliances for creatives in 2026.