# UniFi UNAS Pro Published articles for UniFi UNAS Pro. This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles. ## Debugging my new network, when 10 Gigabit Ethernet Runs at 300 Megabits DevFeed: [Debugging my new network, when 10 Gigabit Ethernet Runs at 300 Megabits]() Original publisher: [Read original article]() Published: 2026-08-27T15:25:48Z Content type: article Language: en Sources: [Scott Hanselman]() Topics: [Homelab](), [debugging](), [UniFi UNAS Pro](), [intel](), [Windows](), [NVMe]() Tags: [debugging](), [homelab](), [intel](), [musings](), [nvme](), [smb](), [ssd](), [storage](), [unifi-unas-pro](), [windows]() ### AI overview A Windows desktop connected to a 10GbE homelab network was limited to roughly 100-200 megabits per second despite 10-gigabit link indications. Direct testing traced the problem to the Windows/NIC path: increasing the Intel E610 driver's receive buffers eliminated discarded packets and improved receive throughput, while disabling IPv4 Large Send Offload V2 raised transmit throughput to 7.03 Gbit/sec. ### Source excerpt I've been moving my home storage over to a UniFi UNAS Pro 8 as part of a larger homelab moderization. My main IRONHEART (the ultimate PC from a few years back) desktop now has an Intel E610-XT2 10GbE card, the NAS is on 10GbE, and there's a Minisforum MS-01 miniPC on the same network with a 10GbE SFP+ connection running Immich and Portainer and a few other things. Everything says 10 gigabit. Windows says 10 gigabit. UniFi says 10 gigabit. SMB copies are using the correct NIC but my file copies are running at around 100 to 200 megabits per second which is sad making. Naturally, I blamed the NAS, and the spinning rust within. The UNAS has six 16 TB spinning disks in RAID 6 and a pair of NVMe SSDs being used as cache. I'm also running Immich on the MS-01, with its photo library living on the UNAS, so there are lots of thumbnails, metadata reads, and little background writes happening. All seem like reasonable suspects. I switched the UNAS SSD cache from read-write to read-only. No meaningful difference. I stopped Immich completely. No difference. I looked at iostat; the disks weren't saturated. We looked at SMB signing and Windows Defender network scanning. Still slow. Then I stopped testing the NAS and ran iperf3 directly between the Windows desktop and the MS-01: iperf3 -c 192.168.1.222 -P 4 133 Mbit/sec Oops. The reverse test was better, but still wrong: iperf3 -c 192.168.1.222 -P 4 -R 1.33 Gbit/sec That's weird. Now the disks, SMB, Immich, RAID, and the NAS itself were completely out of the equation. This was a Windows/NIC problem and it's weirdly asymmetrical. Looking at the Intel adapter statistics shows me... Get-NetAdapterStatistics -Name "Ethernet - 10 Gig Intel" There were nearly a million ReceivedDiscardedPackets. During one ten-second iperf3 test, the counter increased by another 268. Why? The E610 driver had its receive buffers at the default 512, although it supported up to 4096. I increased them. I love an increased buffer. Set-NetAdapterAdvancedProperty ## Unifi UNAS 2 and UNAS 4. - One Year Later DevFeed: [Unifi UNAS 2 and UNAS 4. - One Year Later]() Original publisher: [Read original article]() Author: Rob Andrews Published: 2026-08-26T11:01:27Z Content type: comparison Language: en Sources: [NAS Compares]() Topics: [UNAS 2](), [UNAS 4](), [DRIVE](), [Ubiquiti](), [systems]() Tags: [drive](), [hdd](), [network-attached-storage-nas](), [review](), [storage](), [ubiquiti](), [unas](), [unas-2](), [unas-2-1-year-later](), [unas-2-bad](), [unas-2-good](), [unas-2-nas](), [unas-2-vs-4](), [unas-2026](), [unas-4](), [unas-4-1-year-later](), [unas-4-nas](), [unas-4-ne-year-later](), [unas-4-review](), [unas-review](), [unas-vs-qnap](), [unas-vs-synology](), [unas-vs-ugreen](), [uncategorised](), [unifi-2026](), [unifi-2027](), [unifi-enas](), [unifi-nas](), [unifi-nas-2026](), [unifi-nas-review](), [unifi-unas-2](), [unifi-unas-4](), [unifi-unas-6](), [unifi-unas-pro]() ### AI overview A one-year-later review of Ubiquiti's UniFi UNAS 2 and UNAS 4 desktop storage systems, including their positioning within the UniFi Drive platform and the UNAS 2's two-HDD-bay design for smaller deployments. ### Source excerpt UniFi UNAS 2 and UNAS 4 1 Year Later Review When Ubiquiti introduced the UNAS 2 and UNAS 4 in September 2025, the company was attempting to bring its comparatively simple UniFi Drive storage platform into a pair of compact desktop systems. The UNAS 2 targeted smaller deployments with 2 HDD bays, while the UNAS [...] ## Migrating a Synology NAS to a UniFi UNAS Pro 8 with Robocopy and SMB Multichannel DevFeed: [Migrating a Synology NAS to a UniFi UNAS Pro 8 with Robocopy and SMB Multichannel]() Original publisher: [Read original article]() Published: 2026-08-23T19:23:42Z Content type: tutorial Language: en Sources: [Scott Hanselman]() Topics: [migration](), [UniFi UNAS Pro](), [Synology](), [Filesystems](), [Windows](), [Network]() Tags: [files](), [filesystem](), [migration](), [multichannel](), [musings](), [nas](), [network](), [performance](), [smb](), [synology](), [synology-nas](), [unas](), [unifi](), [unifi-unas](), [unifi-unas-pro](), [windows]() ### AI overview A personal technical account of migrating files from a Synology NAS to a Ubiquiti UniFi UNAS Pro 8. It describes SMB-based copying with Windows and Robocopy, file-transfer errors, Windows error 665, and troubleshooting that isolates a filesystem limitation on the UNAS. ### Source excerpt 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) Cop