Migrating a Synology NAS to a UniFi UNAS Pro 8 with Robocopy, SMB Multichannel, and Surprising Performance Traps - Scott Hanselman's Blog
Scott Hanselman
browse by category or date
Migrating a Synology NAS to a UniFi UNAS Pro 8 with Robocopy, SMB Multichannel, and Surprising Performance Traps
August 23, 2026<br>Comment on this post [0]<br>Posted in Musings
Sponsored By
-->
I’ve had a Synology NAS for a very long time, and recently I started moving its contents to a new Ubiquiti UniFi UNAS Pro 8. This seemed like it ought to be a fairly boring operation. Both devices speak SMB, I have a fast network (recently upgraded to 10 gigabit internally), and Windows has had tools for copying files reliably between machines for decades. Naturally, it turned into a whole evening of learning things I thought I already knew, which is why I started a blog lol.
There was a nice bit of history here for me because back in 2007 (good lord!) I wrote a post called “XCopy considered harmful - Robocopy or XXCopy or SyncBack.” My argument at the time was basically that once you are moving enough files, Explorer stops being the move and Robocopy starts looking pretty good. I even used /Z, Robocopy’s restartable mode, because being able to resume a partially transferred file was useful on unreliable connections.
Almost twenty years later, /Z turned out to be one of the most important things I needed to remove because it made everything hella slow.
The migration
The basic job was straightforward. I had shares on the Synology such as:
\\server\music
and matching shares on the UNAS:
\\UNAS-Pro-8\music
I initially used Explorer, mostly because it was there and because sometimes the easy thing really is the easy thing. That lasted until Explorer started producing errors on individual files:
The requested operation could not be completed due to a file system limitation
My first thought was filenames. NAS migrations are full of opportunities to discover that one filesystem is more permissive than another, and there were filenames with parentheses and other punctuation in them.
Then this failed:
\\server\music\Athlete\Tourist\05 Wires.m4p
There is nothing especially exotic about 05 Wires.m4p, so I moved over to Robocopy to get a little more information. It consistently got to 92% and returned Windows error 665:
92% New File 4.3 m 05 Wires.m4p
ERROR 665 (0x00000299) Copying File<br>The requested operation could not be completed due to a file system limitation
At this point the useful question was no longer “what is wrong with that filename?” but “which part of the path is refusing this file?”
I copied the file from the Synology to my local Windows desktop. That worked. I then copied the local file from Windows to the UNAS, and that failed with the same filesystem limitation.
That isolated the problem so the Synology could read the file, Windows could store it, and something about writing this particular file to the UNAS was causing trouble.
Alternate Data Streams, again
NTFS files can contain named Alternate Data Streams in addition to the ordinary unnamed stream that we usually think of as the contents of a file. This is an old Windows filesystem feature, and it happens to be one I wrote about in 2007 when discussing Zone.Identifier, which Windows can use to record where a downloaded file came from. I even blogged about Alternate Data Streams in 2003!!! Windows can expose these streams with DIR /R.
So I ran:
dir /r "%USERPROFILE%\Desktop\05 Wires.m4p"
and got:
11/30/2011 02:17 PM 4,576,368 05 Wires.m4p<br>360,456 05 Wires.m4p:01APIC_03.jpg:$DATA
There it is. Alongside the normal 4.5 MB music file was a roughly 360 KB named data stream called 01APIC_03.jpg.
That also explained the strange 92% failure. Robocopy was successfully getting through the main contents of the file and then encountering the additional stream. What had looked like a failure somewhere in the middle of an ordinary .m4p file was actually occurring when Windows attempted to deal with the additional filesystem data.
Robocopy has support for exactly this situation. Microsoft documents X as one of the /COPY flags, meaning “skip alternate data streams.” So:
/COPY:DATX
means copy the file’s data, attributes, and timestamps, but do not copy the alternate streams. /DCOPY:DATX applies the corresponding behavior to directories. I retried the same file:
robocopy "\\server\music\Athlete\Tourist" "\\UNAS-Pro-8\music\Athlete\Tourist" "05 Wires.m4p" /R:0 /W:0 /COPY:DATX /DCOPY:DATX /V
and it completed successfully. The important distinction here is that DATX does not remove metadata stored inside an MP3, M4A, M4P, JPEG, or other file format. It tells Robocopy not to reproduce separate filesystem streams associated with the file. In my case those extra streams were not something I needed to preserve on the new NAS.
The copy worked, but it was slow
Once the ADS issue was understood, I started...