NAS transfer speed dropping to zero mid-copy can have several causes, including a bad network cable, SMB configuration, drive or NAS power settings, a failing drive, a network switch issue, a NAS resource bottleneck, or a client-side problem. These checks can help narrow the cause, but symptoms can overlap and the time required to resolve the problem varies. This guide works through each one in the order that accounts for the most cases.
In short: Start by testing with a different cable. If the problem persists, check whether the NAS is configured to spin down drives or enter HDD hibernation during transfer (turn it off temporarily for testing). If still dropping, run a network ping test during the drop to distinguish network loss from NAS-side issues. Sustained ping loss indicates loss of basic IP reachability and warrants checking the entire path and both endpoints; it does not uniquely identify the cable or switch. Stable ping with zero transfer shows that basic ICMP/IP reachability remains, but the cause may still be in SMB, TCP, the client, the NAS OS or the storage layer.
Before You Start: The Diagnostic Ping Test
The single most useful diagnostic step is to ping your NAS continuously while a transfer drops to zero. On Windows, run ping -t 192.168.x.x. On macOS, run ping 192.168.x.x; it continues until you stop it with Control-C. Start a large file transfer, let it run, and watch the ping output when the transfer stalls.
If ping loss or an unusual latency increase coincides with the stall, investigate the network path and endpoint responsiveness, but do not treat ping alone as proof of a cable, switch or NAS-interface fault. If ping remains stable while the transfer stalls, basic IP reachability is intact, but TCP/SMB, client-side software, client storage and NAS-side causes still need investigation. This single test narrows the diagnosis before you spend time investigating the wrong layer.
Cause 1: Faulty or Poor-Quality Network Cable
A defective Ethernet cable is the most underdiagnosed cause of intermittent NAS transfer drops. Unlike a completely failed cable that prevents connection entirely, a marginal cable negotiates a connection and runs correctly for a few seconds before bit errors cause the connection to briefly reset. The transfer appears to stall. After a second or two, the connection recovers and the transfer resumes - or not, depending on how bad the cable is.
To diagnose: Swap the Ethernet cable between the NAS and your switch with a different cable you know is good. If the problem disappears with the new cable, the original cable was faulty. Even cables that look undamaged physically can have internal wire breaks from being bent or kinked. Try cables from a reputable brand - no-name patch cables sold in bulk can have inconsistent quality.
To check for errors: On Synology DSM, open a terminal session (via Control Panel, then Terminal and SNMP, then Enable SSH) and run ifconfig eth0. Compare the counters before and during a reproduced stall. Rising CRC, carrier or other hardware-error counters are relevant, but non-zero dropped counters alone do not identify a bad cable. On QNAP, the same check is available through the Network and Virtual Switch manager.
Cause 2: Drive or HDD Hibernation
Both Synology DSM and QNAP QTS include a drive hibernation feature that spins down drives after a period of inactivity to save power and reduce wear. The delay while drives leave standby varies by drive and NAS. Drive hibernation can delay access when disks were already idle before the transfer, but vendor documentation says standby begins only after the configured period without disk access and ends when the system accesses the drives.
To check on current Synology DSM: Go to Control Panel, then Hardware & Power, then Drive Hibernation. On DSM 7.2 and earlier, the page is named HDD Hibernation. Look at the HDD Hibernation setting. If it is enabled and set to a short interval (such as 5 or 10 minutes), try disabling it temporarily and retesting your transfer. If the transfer completes without drops, hibernation is the cause.
To check on current QNAP QTS: Go to Control Panel, then System, then Hardware, then General, and look for Enable disk standby mode. Disable or extend the standby interval for testing.
Drive hibernation is worth keeping enabled during normal idle use - it extends drive life and reduces power consumption. The fix is to extend the interval (30-60 minutes instead of 5), not to disable it permanently. A transfer that takes 20 minutes will not trigger a 30-minute hibernation window.
Cause 3: SMB Timeout and Protocol Version Mismatch
SMB (the network file-sharing protocol Windows uses to communicate with the NAS) has several versions and configuration options that affect transfer stability. SMB1 is deprecated and no longer installed by default in modern Windows; Microsoft warns against enabling it because of known security issues. If the NAS supports only SMB1 and the Windows client has SMB1 disabled or uninstalled, SMB negotiation fails rather than producing a successfully established connection that drops only during large transfers.
To check on Synology: Go to Control Panel, then File Services, then SMB. Ensure the minimum SMB protocol is set to SMB2 and the maximum to SMB3. SMB3 supports recovery features such as durable or persistent handles, but whether an interrupted operation survives depends on the client, server and share configuration; selecting SMB3 alone does not guarantee that a file copy will resume. If you have SMB1 enabled, disable it. If the minimum protocol is SMB1, change it to SMB2.
Large transfer timeout: On Windows, large SMB transfers can time out if the NAS response is delayed. This is configurable in the Windows registry via HKLM\SYSTEM\CurrentControlSet\Services\LanmanWorkstation\Parameters - look for SessTimeout and increase it from the default (if it exists). Use SMB2 or SMB3 and keep SMB1 disabled for security, but change SessTimeout only after confirming that an SMB request timeout is the actual cause.
Cause 4: Network Switch Issue
An overloaded, failing, or misconfigured network switch can cause intermittent connection drops that manifest as transfer stalls. The ping test above distinguishes a switch problem from a NAS-side problem - if ping drops at the same time as the transfer, start investigating the switch.
Try connecting the NAS and your computer directly to the router (bypassing the switch) to confirm whether the switch is the cause. If transfers work reliably with a direct router connection, the switch is faulty, overloaded, or has a bad port. Try moving the NAS and computer to different ports on the switch. If the switch is unmanaged and several years old, a failing switch is worth replacing - quality 5-port or 8-port Gigabit switches cost under $50 and a 2.5GbE switch for NAS setups is available from brands including TP-Link and QNAP for $80-150.
Cause 5: Drive Health Issues
A drive that is beginning to fail will generate read errors during transfer. When a drive encounters a read error, its firmware and the storage controller may retry or reconstruct the read; recovery time varies by drive, controller and error-recovery configuration and can stall I/O. For a single bad sector, the delay is barely noticeable. For a drive with widespread surface degradation, those retries accumulate into a sustained stall while the controller attempts to read a large swath of problematic sectors.
To check on Synology: Open Storage Manager, then HDD/SSD. Check each drive's health status and run an S.M.A.R.T. quick test on any drive showing warnings. These attributes are relevant, but raw-value meanings and warning thresholds vary by drive vendor. Review the NAS health status, the drive manufacturer's interpretation and whether the values are increasing. A drive with pending sector errors should be replaced before it fails completely.
To check on current QNAP QTS: Open Storage & Snapshots, then Storage, then Disks/VJBOD, select a disk, and click Health. QNAP's S.M.A.R.T. test is available per drive from the same interface.
If S.M.A.R.T. shows any Uncorrectable Sector Count above zero, treat this as an early drive failure warning. Back up all data to a separate device immediately and replace the drive before it fails completely. Redundant RAID can recover from some reported sector-read errors, and checksum-enabled filesystems with supported RAID may detect and repair some silent corruption. RAID is not a backup, so maintain a separate current backup.
Cause 6: NAS CPU or RAM Overload
If the NAS is running other resource-intensive tasks alongside a large file transfer - a RAID rebuild, an antivirus scan, a Plex transcode, or a backup job - the NAS's CPU or RAM can saturate. When the transfer process competes with other processes for resources, it stalls intermittently while waiting for CPU time.
To check on Synology: Open Resource Monitor (available in the DSM application menu). Watch CPU usage during a transfer drop. Sustained high CPU coinciding with the stall can indicate contention, but interpret it with process usage, load average, I/O wait, disk activity and swap behavior rather than using a universal percentage cutoff. Identify which process is consuming CPU - a background antivirus scan or a RAID rebuild are common culprits. Schedule resource-intensive tasks for off-hours rather than running them simultaneously with large transfers.
On QNAP: Open Resource Monitor from the QTS desktop. The same CPU and RAM monitoring applies. QNAP's Resource Monitor also shows network throughput per interface, which helps confirm whether the bottleneck is network-side or processor-side.
Related reading: our NAS buyer's guide.
Use our free Transfer Speed Estimator to estimate how long large transfers will take over your connection.
Related reading: our NAS explainer.
See also: our complete Synology NAS Australia guide.
See also: our complete QNAP NAS Australia guide.
My NAS shows full Gigabit speed for 30 seconds then drops to zero. What is the most likely cause?
This cycling pattern does not uniquely identify a cause. Check cabling and interface counters, but also investigate SMB, client-side software, NAS resource usage and drive I/O; hibernation is relevant chiefly when drives were already idle before access. The cycling pattern suggests the connection is recovering after each drop rather than failing permanently. Start by swapping the cable, then disable HDD hibernation for testing. If the transfer runs cleanly after disabling hibernation, extend the hibernation interval to 30 minutes rather than disabling it permanently.
Does this happen more with large files or small files?
Drive hibernation can delay the first access when drives were already idle, but transfer length alone should not trigger standby because active disk access resets the inactivity condition. SMB timeout issues often manifest during transfers that stall briefly mid-file. Cable errors can occur at any file size but tend to be more noticeable with large files because the connection has more time to encounter a fault. If the problem only happens with large files, hibernation or SMB timeout is more likely. If it happens immediately with even small files, cabling or switch is more likely.
Will upgrading to 2.5GbE help?
Not if the problem is drive hibernation, SMB configuration, or drive errors - those affect transfers regardless of link speed. 2.5GbE provides 2.5 times the nominal link rate of Gigabit Ethernet, but real file-transfer throughput is lower than the raw bit-rate conversion and depends on protocol overhead and both endpoints. Diagnose the current problem first. A faulty $5 cable causing drops will not be fixed by a $100 2.5GbE upgrade.
The transfer only drops when other people are using the NAS simultaneously. Is this normal?
Yes and no. Some throughput reduction under concurrent load is normal - the NAS shares bandwidth and CPU across all connections. But a complete drop to zero is not normal, even under load. Check the NAS's CPU and RAM usage during the drop. If the NAS is maxing out its processor from concurrent requests, you may need a more capable NAS model or need to schedule heavy tasks (backups, Plex transcoding) during off-hours. On an underspecified NAS, multiple 4K streams plus a large copy can genuinely saturate the CPU.
I replaced the cable and disabled hibernation but the problem persists. What next?
Run the diagnostic ping test during a drop. If ping drops too, focus on the network layer - try a different switch port, a different switch, or a direct router connection. If ping stays solid but transfer drops, focus on the NAS layer - run a S.M.A.R.T. test on all drives, check for RAID degradation in Storage Manager, and look at Resource Monitor for CPU/RAM saturation during the drop. Also check the NAS's system log for any error messages around the time of the drops.
Can antivirus on my PC cause NAS transfer drops?
Yes. If your PC's antivirus is scanning every file as it is received from the NAS, it can throttle the transfer while it scans each incoming file. This is particularly noticeable with antivirus products that do real-time scanning with heuristic analysis. Try pausing your antivirus temporarily during a test transfer to confirm. If testing implicates antivirus, follow the antivirus vendor's performance-troubleshooting guidance and use the narrowest necessary exclusion only after assessing the security impact. Files on a NAS can still contain malware.
Is your NAS not showing up on the network at all? That is a different problem with different causes. The NAS not detected guide covers the full diagnostic sequence.