NAS OS and storage stack 2026: a portability-first survey

Decision. Pick TrueNAS Community Edition on ZFS if you want the most polished single-admin snapshot/replication GUI [2] [67] and accept periodic Apps-stack rewrites [40] [64]. Pick Unraid 7.x if data portability matters most — every array disk is an independent filesystem readable on any Linux box [42] — and you want 2000+ pre-configured Docker apps [73], with the catch of a paid licence model [4]. Pick OpenMediaVault 8 if you want a thin Debian veneer with full apt escape hatch [47]. Pick plain Debian + ZFS + Cockpit + zrepl if you already live in Linux and want zero appliance abstractions [12] [77]. ZFS (OpenZFS 2.3+) is the default storage layer; btrfs RAID5/6 is still officially unsafe [26], bcachefs was removed from mainline in 6.17 [29], and SnapRAID + mergerfs is the right pattern only for cold-ish media archives [34]. Synology SHR drives mount on vanilla Linux via mdadm + LVM + btrfs [37], but Hyper Backup and Active Backup repositories are DSM-only [55] [61] — replicate the live data, don’t trust the backup format.

Why this question, why now

DSM 7.2’s 2025 storage-pool drive lock-in (Synology-branded HDDs only) prompted enough sales pain that DSM 7.3 reversed it in October 2025; firmware updates and health telemetry remain first-party-only [17]. That is the migration trigger most operators hit in 2026. The replacement candidates have meanwhile converged on a smaller, sharper set of options.

The five OS options at a glance

NixOS is technically viable for declarative ZFS NAS configs but its ZFS module pins to LTS kernels and the language/docs friction makes it a poor fit for casual operators [13] [14]. Skip unless you already run Nix elsewhere.

Hardware-compat footnotes that bite

Realtek RTL8125 2.5GbE NICs cap at 1G on TrueNAS’s stock r8169 driver and need an out-of-tree r8125 driver reinstalled after every TrueNAS upgrade [15]. Intel iGPU QuickSync on TrueNAS Apps relies on the i915 kernel driver and per-app GPU surfacing for Plex/Jellyfin [16]. On plain Debian both work without ceremony.

The storage stack layer

Choose this independently from the OS: ZFS works on TrueNAS, Unraid pools, Proxmox, OMV (plugin), and plain Debian.

ZFS RAM and ECC: kill the folklore

The “1 GB of RAM per TB of storage” rule is folklore, not OpenZFS guidance — official docs just recommend “8GB+ for best performance” and confirm ZFS runs on 2GB [22] [23]. ECC is recommended but not strictly required; co-creator Matt Ahrens has been quoted to that effect, with the caveat that ECC blocks an in-RAM bit flip from being written as a “valid” but corrupt block [24]. RAIDZ expansion (the long-missing feature) shipped in OpenZFS 2.2 and broadly in 2.3 (Jan 2025) — pool stays online and fault-tolerant during the multi-day reflow [19] [20].

Lock-in vectors: four layers, scored

Lock-in is not one thing. Score every option on these four layers, weight them by your own exit fear:

1. Volume layer — can the disks be read by another OS?
2. Identity / share — does the SMB user database and ACL set transfer?
3. App / container runtime — are workloads portable, or trapped in a vendor format?
4. System config — can you replicate the box on different hardware from text files?

The clearest portability wins: Unraid for the volume layer (any disk works in any Linux box), plain Debian for everything else. The clearest portability loss: TrueNAS Apps, which was rewritten in 24.10 (Cobia/Dragonfish k3s → Electric Eel Docker Compose [64]); plan for periodic apps-stack rewrites and budget redeploy effort accordingly.

Migration: getting off Synology, and between stacks

Synology SHR → vanilla Linux (the byte-rescue play)

The disks are standard Linux: mdadm software RAID under LVM2 under btrfs/ext4 [37]. Documented incantation for a multi-disk SHR1 set, mounted read-only [36] [53] [54]:

sudo mdadm --assemble --scan --force --run     # rebuild arrays
sudo vgchange -ay --activationmode partial      # bring up VG
sudo mount -o ro /dev/mapper/vg1000-lv /mnt/syn

Single-disk SHR1 is trivial; multi-disk is more fragile because miscalculating sub-array stripe alignment can corrupt the volume [36]. Modern kernels (5.4+) reject Synology’s old btrfs format unless you fall back to an Ubuntu Bionic 4.15 kernel [36] — keep an Ubuntu 18.04 ISO in your toolkit. A documented 2024 Synology→Unraid run saw rsync -a --info=progress2 push ~140 MB/s through an Ubuntu VM holding the donor disk [54].

What does not survive

• Hyper Backup repositories are a proprietary deduplicated .HBK container, only readable by Synology Hyper Backup, HB Vault, or DSM bare-metal restore [55]. No open reader. Treat them as DSM-only.
• Active Backup for Business archives are similarly DSM-locked; the ABB UI can export individual files but the backup catalog cannot be ingested by TrueNAS/Unraid/OMV [61].
• Share definitions, the SMB user database, and per-share ACLs. TrueNAS’s own third-party migration doc requires you to pre-create matching local accounts before migration so NFSv4 ACLs / Windows SDs resolve [56]. A community toolkit (wallacebrf/Synology-to-TrueNAS ⭐ 82 [62]) automates the SMB-pull side, but you still rebuild users by hand.

The byte transfer itself

rsync -aAXH is the universal fallback (archive + ACLs + xattrs + hardlinks). Two gotchas: rsync <3.1.2 may drop NFSv4 ACLs, and Synology’s bundled rsync historically ships without ACL/xattr support, so the pull must originate from a modern Linux side, not the Synology side [59]. Community consensus on r/truenas is rsync over SSH inside tmux, or mounting Synology’s SMB share read-only on TrueNAS; Hyper Backup’s “rsync Single Copy” mode works but has been observed sitting at 100% for ~a week before finalizing on multi-TB sets [60].

Between stacks (post-migration moves)

Day-to-day operator experience

What does this look like in week 6 when a drive throws a SMART error and you’re on holiday?

Snapshots and replication

Alerting

OS upgrades (where each one bites)

• TrueNAS CE: Cobia → Dragonfish broke k3s for many users [66]; 24.04 → 24.10 (Electric Eel) ripped k3s out entirely and replaced with Docker Compose [40]; auto-migration deadline was 1 Jun 2025, manual redeploy after [41]. Users reported all-apps-gone-after-upgrade scenarios on Cobia [65]. TrueNAS 26’s annual cadence (LTS-style on Linux 6.18) is iX’s response to the apps churn [1] [18].
• Unraid 6 → 7: comparatively smooth; 7.1 added ZFS pool import, 7.2 enabled RAIDZ expansion, 7.3-rc Apr 2026 ships ZFS 2.4.1 + Docker v29 + TPM-based licensing [5] [6]. The pricing change (March 2024) drew loud STH backlash — “people will flock to truenas” [69] — but the technical upgrade path itself is fine.
• Proxmox VE 8 → 9: standard Debian 12→13 dist-upgrade, ZFS pools import without migration; 9.1 added OCI/Docker as first-class application containers [10] [76]. 8.4 supported until Aug 2026 [11].
• OMV 7 → 8: reportedly breaks the docker-compose plugin — shared-folder paths get unmapped, containers disappear from the UI, requires a fix7to8upgrade script [81].
• Plain Debian + ZFS: the recurring footgun is unattended kernel upgrades leaving the new kernel’s initrd without ZFS modules, dropping the system to an initramfs shell [78]. Recovery means booting a live env, importing pools read-only, then rebuilding zfs-dkms against the new kernel [79]. Pin kernels or hold zfs-dkms updates.

Container/VM workloads

• TrueNAS CE Apps: Docker Compose since 24.10 (one breaking rewrite, expect more) [40] [64].
• Unraid Community Apps: 2000+ pre-configured Docker containers from the WebGUI — by far the most beginner-friendly app store [72] [73].
• Proxmox: Docker-in-LXC requires nesting + keyctl, exposing /sys and /proc with read-write — official Proxmox docs warn this risks container breakout, recommend Docker-in-VM [75]; 9.1’s native OCI support is the cleaner path [76].
• OMV: not first-party — openmediavault-compose plugin from omv-extras [80].
• Plain Debian: bring-your-own docker compose, fully portable.

Decision recipes

Map your fear to a stack:

Cross-cutting rules

• Replicate live data, not backups. Hyper Backup and ABB are DSM-only formats — you cannot recover from them on the new stack [55] [61]. Move bytes, not archives.
• If you choose ZFS, choose raw replication from day one. A single non-raw zfs receive permanently blocks future raw incrementals into that dataset [57].
• Do not run nested ZFS-on-ZFS. TrueNAS-as-VM-on-Proxmox-with-ZFS is repeatedly warned against — pass the HBA through, or run Samba on the Proxmox host [74].
• Btrfs RAID5/6 → don’t. Synology themselves run btrfs on top of mdraid+LVM rather than native btrfs RAID [28] [53], and the upstream status page still calls native RAID5/6 unstable in 2026 [26].
• Bcachefs is a 2027+ conversation. DKMS-only, hard freeze, ejected from mainline — not a NAS choice in 2026 [29] [30].
• Pin your kernel if you’re on Debian + ZFS. Unattended kernel upgrades + missing zfs-dkms = initramfs shell on next boot [78] [79].