Synology to UniFi UNAS Pro 8 migration tripped by NTFS data streams and Robocopy's /Z flag

A routine NAS swap turns into a debugging session

Scott Hanselman, writing on his blog in a post that surfaced on the front page of Hacker News, recently moved shares from a long-serving Synology NAS to a Ubiquiti UniFi UNAS Pro 8 over a freshly upgraded 10-gigabit internal network. Both endpoints speak SMB and Windows has shipped reliable file-copy tooling for decades, so he expected a boring evening. It was not.

He started in Explorer, which failed on individual files with the message "The requested operation could not be completed due to a file system limitation." One of the failures was an entirely unremarkable track called 05 Wires.m4p. Switching to Robocopy for better diagnostics, the same file died at exactly 92 percent every run, reporting Windows error 665.

Isolating the fault

Rather than blame punctuation in filenames, Hanselman bisected the path. Copying the file from the Synology to his Windows desktop worked. Copying that local file from Windows to the UNAS failed with the identical error. The Synology could serve it, local NTFS could hold it, and only writing this particular file to the new box triggered the limitation.

Running dir /r on the local copy exposed the cause: next to the 4.5 MB audio data, the file carried a named Alternate Data Stream of roughly 360 KB called 01APIC_03.jpg. ADS is a decades-old NTFS feature that attaches extra named streams to a file beyond its usual contents. It also explained the strange 92 percent mark: Robocopy was finishing the main file and then choking on the extra stream.

The fix: /COPY:DATX

Robocopy documents an X copy flag that skips alternate data streams. So /COPY:DATX moves the file's data, attributes and timestamps while leaving named streams behind, and /DCOPY:DATX applies the same rule to directories. Retried with those flags, the problem file copied cleanly.

Hanselman stresses the distinction: this does not strip metadata embedded inside MP3, M4A, M4P or JPEG files, only the separate filesystem-level streams attached to them. In his case those streams were not worth carrying over to the new NAS.

/Z was the silent bottleneck

With errors solved, the bulk migration ran but throughput swung wildly, from a few hundred megabits per second down to near stalls on small files. He suspected buffering, slow disks, parity calculations, SMB behavior on the UNAS, or an aging Synology. Cutting Robocopy's thread count, even to single-threaded, changed nothing. Removing /Z did.

/Z enables restartable mode, letting an interrupted file resume instead of restarting from byte zero. Hanselman had defaulted to it since writing about Robocopy versus XCopy in 2007, but Microsoft's current migration guidance specifically cautions that the extra logging restartability requires can significantly cut copy performance.

His final music-library command ran /E /MT:4 /R:2 /W:2 /COPY:DATX /DCOPY:DATX /XJ /TEE with a log file, and finished 15,940 files with zero failures: 6,991 copied, 8,949 skipped, with just under 48 GB of remaining data moving at an average of about 187 MB per second.

He is candid that this was not a controlled benchmark isolating one variable at a time, so the number does not prove /Z caused every bit of the earlier slowdown. The practical gap was large enough that he now starts LAN migrations without the flag and adds it only when resumability genuinely matters.

/MT overlaps per-file overhead, nothing more

Robocopy's /MT:n option runs between 1 and 128 threads, defaulting to eight when supplied bare, and Microsoft's guidance notes that more threads do not automatically mean faster migrations. Hanselman's mental model is that threads do not make one file copy faster; they overlap the fixed per-file work of opening, creating, writing, handling metadata and closing, so the network and disks stay busy across many small files. For a library of thousands of tracks, four threads hit the sweet spot, sixteen did not obviously help, and one was no improvement. He warns against treating any particular value as a universal default.

Why it matters

Box-to-box NAS migrations are where filesystem mismatches surface, and Windows error 665 caused by alternate data streams is easy to misread as a filename problem. The generalizable playbook is to bisect the copy path, use dir /r to inspect streams, and reach for /COPY:DATX when they are not worth preserving. Equally important, Robocopy habits calcify: flags that made sense on unreliable 2007-era links, like /Z, can dominate a copy on a modern 10GbE LAN, while /MT is a workload-tuning knob rather than a magic constant. For self-hosters planning their own Synology-to-UNAS move, the post doubles as a compact checklist of the traps most likely to bite.