I'm getting extremely slow SMB file transfers from my Windows PC to a hard drive connected to an OpenWrt router. In File Explorer, both reads and writes usually stay around 1.5–2 MB/s and never go above roughly 3 MB/s, even though Windows reports a 1 Gbps wired link. The same drive and share reach about 33 MB/s from a Mac and an Android TV using SMB or DLNA.
I've tested three Ethernet cables, installed the latest Realtek driver for my Gigabyte B650M Aorus Elite motherboard, tried the default Windows driver, and disabled several adapter power-saving and energy-efficiency options. Windows and its updates are current. The router is a Xiaomi Mi Router 3G running OpenWrt with Samba 4, and it has a hard drive connected by USB. Switching the Windows PC to Wi-Fi produced the same slow results. I also tried enabling Windows' SMB file-sharing features, but that did not help.
What Windows-specific setting, protocol issue, or diagnostic test could explain this bottleneck when other devices transfer normally?
3 Answers
Installing the SMB feature probably won’t fix this by itself—modern Windows already includes the SMB client needed for normal SMB 2/3 shares. I’d avoid enabling the obsolete SMB 1.0 feature unless the server specifically requires it. Check Windows Event Viewer and PowerShell’s SMB connection information for errors or an unexpected dialect, then try mapping the share by IP address instead of hostname to rule out name-resolution delays.
The router is still worth checking even though the other clients are faster. Different clients can negotiate different SMB dialects, signing, encryption, or authentication behavior. Compare the negotiated SMB connection from Windows with the Mac, and temporarily test a share with SMB signing or encryption disabled if those are enabled. On the router, watch CPU usage and disk I/O while copying; an old router can become CPU-bound for one particular SMB mode.
Since Wi-Fi shows the same behavior, the Ethernet cable, link negotiation, and most adapter hardware settings are unlikely to be the cause. The next useful step is to separate File Explorer from SMB itself: test a large single file with a command-line copy, and compare that with a tool such as Robocopy. Also check whether antivirus or Windows security software is scanning every file during the transfer. A sustained transfer of one large file is more useful than copying many small files, since SMB metadata and file-open overhead can make small-file copies look extremely slow.
The fact that changing drivers and using Wi-Fi made no difference points away from the physical network path. A command-line test with one large file, plus checking the SMB dialect and security settings, should help identify whether the slowdown is Explorer, Windows security scanning, or the SMB session itself.