DB-유

Fixing Slow Transfers over SMB on Synology

· synology, smb, performance, networking

"The NAS is slow" is the ticket I get most often. A gigabit link should move around 110 MB/s in either direction, and a healthy Synology with a RAID 5 of spinning drives does that on large files. When users report 20 MB/s copies, folders that take ten seconds to open, or transfers that stall and burst, it's almost never the disks. It's somewhere between the client's SMB stack, the network and the SMB service settings.

Here's the checklist I work through, in the order that finds the problem fastest. Have DSM admin and SSH access, a wired test client (Wi-Fi results are meaningless here), a large test file of a few GB, and a folder with a few thousand small files.

Rule out the disks first

Measure the volume itself before blaming the network:

sudo dd if=/dev/zero of=/volume1/office/ddtest bs=1M count=4096 conv=fdatasync
sudo dd if=/volume1/office/ddtest of=/dev/null bs=1M
rm /volume1/office/ddtest

Anything above 150 MB/s means the disks are not the bottleneck for a single gigabit client. If write speed is far lower, look at Storage Manager for a degraded volume, a running data scrub or RAID resync, or an SSD cache flushing.

Then test raw network throughput independent of SMB with iperf3. Install it in a container to avoid touching DSM:

sudo docker run --rm -it --net=host networkstatic/iperf3 -s

And from the client iperf3 -c <nas-ip>. Expect 940 Mbit/s or so. Less than that points to the switch, the cable or the NIC settings, not to Synology.

sudo ethtool eth0 | grep -E "Speed|Duplex"
sudo ifconfig eth0 | grep -E "errors|dropped"

100Mb/s here explains everything; it usually means a damaged cable or a switch port that failed autonegotiation. Errors and drops incrementing indicate a cable or a duplex mismatch.

If you use Link Aggregation (Control Panel → Network → Network Interface → Create → Bond), remember that a single client still gets one link's worth of bandwidth; bonding helps many clients, not one.

Jumbo frames (MTU 9000) help a little on Synology CPUs but only if every device in the path supports them. Enable them on the NAS under Network Interface → Edit → Set MTU value, on the switch, and on each client's adapter; a single device left at 1500 causes exactly the stall-and-burst pattern people complain about. When in doubt, leave MTU at 1500 everywhere.

SMB service tuning

Control Panel → File Services → SMB → Advanced Settings:

  • Maximum SMB protocol: SMB3. Minimum: SMB2. SMB1 lacks large reads and pipelining and is slow on top of being insecure.
  • Enable Opportunistic Locking and SMB2 lease: both on. Without them Office and Explorer round-trip for every small operation.
  • Enable SMB durable handles: on for Windows clients.
  • Transport encryption mode: Auto, not Force. On Celeron models forced encryption cuts throughput roughly in half.
  • Disable "Enable asynchronous read" only if you see corruption complaints; otherwise leave on.
  • Under Others, "Collect debug logs" must be off; it slows every operation.

Uncheck "Enable Recycle Bin" is not a speed fix, but be aware that shared folders with a recycle bin containing hundreds of thousands of items make deletes slow. Empty it.

For folder browsing speed, the killer is DSM's file indexing and thumbnail generation running against a share that is being browsed. Control Panel → Indexing Service: remove folders that do not need media indexing. Check Resource Monitor for synoindexd or convert processes eating CPU during the slow periods.

The clients

Windows 10:

Get-SmbConnection | Select-Object ServerName, Dialect
Set-SmbClientConfiguration -EnableLargeMtu $true -EnableMultiChannel $false

Dialect must show 3.x. If Windows is negotiating 2.0.2 with a Synology on DSM 6.2, something on the client forces it down; check Get-SmbClientConfiguration. Also disable "Remote Differential Compression" in Windows Features if copies of large files are slow, and check that third-party antivirus is not scanning network drives on access.

macOS, when Finder is slow to list directories over SMB, create /etc/nsmb.conf:

[default]
signing_required=no
dir_cache_max_cnt=0

The signing setting matters most: some macOS versions default to requiring SMB signing, which can halve throughput to a NAS. Disable it only on trusted LANs.

Confirming the fix

Copy the large test file both ways from a wired Windows client and watch Task Manager's network graph; it should sit flat near 900 Mbit/s. Open the folder with thousands of small files; Explorer should list it in a second or two. On the NAS:

sudo smbstatus -b

confirms the connection dialect per client. Resource Monitor → Network on the NAS should show the same throughput as the client.

Odd symptoms

  • Transfer starts fast and drops to a crawl after a few hundred MB: the client's write cache filled and the real disk speed is showing, or the NAS is on a 100 Mbit port and buffering hid it. Recheck ethtool and the dd test.
  • Only one PC is slow, others are fine: that PC's NIC driver or power management. Update the driver and disable "Energy Efficient Ethernet" and "Green Ethernet" in its adapter properties.
  • Small files are slow, large files are fine: latency-bound behavior. Check oplocks and leases are on, and that no antivirus on the client scans each file; on the NAS, look for the indexing daemon.
  • Mac copies stall with "The Finder can't complete the operation because some data in ... can't be read or written (Error code -36)": usually .DS_Store writes on a share with restrictive ACLs, or SMB signing negotiation. Apply the nsmb.conf settings and check the share permissions.

Most of these end at the link check with a bad cable or a port stuck at 100 Mbit. I now swap the cable before I touch a single setting.