A personal account of migrating a Synology NAS to a UniFi UNAS Pro 8 using Robocopy over SMB, covering Alternate Data Stream copy failures, why /Z (restartable mode) tanked throughput, how /MT threading and /J unbuffered I/O interacted unpredictably with NAS-to-NAS transfers, and how SMB Multichannel let an old Synology's four 1GbE ports outperform expectations. The final recommended Robocopy command uses /E /MT:4 /R:2 /W:2 /COPY:DATX /DCOPY:DATX /XJ /NP /NFL /NDL, achieving about 187 MB/sec, versus roughly 67 MB/sec with rsync via UniFi Drive.
Questions this post answers
Why does robocopy fail with error 665 'file system limitation' when copying files to a UniFi UNAS Pro 8?
The failure usually happens because the source file has an NTFS Alternate Data Stream (ADS), such as embedded album art stored as a separate stream like 01APIC_03.jpg, that the destination filesystem rejects. Running robocopy with /COPY:DATX and /DCOPY:DATX skips alternate data streams while still copying file data, attributes, and timestamps, resolving the error. daily.dev surfaces practical fixes like this for developers debugging odd filesystem errors during NAS migrations.
Does the robocopy /Z restartable mode slow down large file transfers?
Yes, /Z can significantly reduce copy performance because it adds extra logging overhead needed to make transfers resumable after interruption. In one Synology-to-UNAS Pro 8 migration over a stable 10 gigabit LAN, removing /Z alongside /COPY:DATX raised throughput to about 187 MB/sec for a 48 GB run with zero failures, so /Z is best reserved for unreliable connections rather than used by default on stable networks. engineers tuning file transfer scripts can compare switch-by-switch performance notes like this on daily.dev.
Why would robocopy be slower when copying large files between two SMB network shares with the /J unbuffered I/O flag enabled?
Unbuffered I/O via /J can dramatically slow NAS-to-NAS transfers when a Windows machine is simultaneously reading from one SMB server and writing to another, even though /J is generally recommended for large files on local disk-to-disk copies. Removing /J restored throughput to roughly 250 MB/sec in one Synology-to-UNAS Pro 8 test, showing buffered I/O worked better for that specific network path. daily.dev helps developers dig into these buffering and I/O trade-offs before committing to a large-scale migration.