TrueNAS Scale, TrueNAS Core, and openmediavault
Until fairly recently, DIY NAS builders setting up a new storage server had two main choices: FreeNAS and openmediavault. The backstory of these projects is interesting. FreeNAS was released in 2005 by developer Olivier Cochard-Labbé, who eventually lost interest in the project. By 2009, the only active FreeNAS developer was Volker Theile, who proposed migrating the project to a Linux base instead of the then-current m0n0wall, which itself was based on embedded FreeBSD. Olivier declined to take the project in that direction, and Volker left FreeNAS to create a new system, openmediavault, based on Debian Linux. Olivier transferred the rights to FreeNAS to the US-based company iXsystems, which has handled the project’s development and promotion ever since.
info
Small world: openmediavault is developed and maintained by a former lead developer of FreeNAS.
Over time, iXsystems introduced a commercial edition called TrueNAS. A bit later, the free FreeNAS and commercial TrueNAS branches were merged, and more recently the unified TrueNAS split again into two projects: TrueNAS Core, based on FreeBSD, and TrueNAS Scale, which runs on Debian 11 (Bullseye).
So, as of today, the choice comes down to three similar yet very different systems: TrueNAS Core, TrueNAS Scale, and openmediavault. To start, here’s a table comparing the key parameters I’ve chosen for these three systems.

(* Migration of encrypted GELI volumes is described in the documentation)
Now, let’s break down the table.
Developer
Both systems are available as ready-to-use distributions and as open-source code. Both editions of TrueNAS are developed and maintained by iXsystems, which monetizes the platform through licensing of the commercial edition (including to large enterprises), selling turnkey NAS appliances with TrueNAS preinstalled, and providing support and maintenance services.
OpenMediaVault is developed by a single developer, Volker Theile, and support is provided through the forum. I even had a chance to speak with Volker; he’s friendly and highly professional—despite not earning a cent for his work.
Underlying OS and UI
All three solutions are built on top of UNIX-like systems. TrueNAS Core runs on FreeBSD with all its quirks (notably monolithic updates and its own driver stack distinct from Linux), along with its strengths and weaknesses—the most significant being the lack of Docker support and incompatibility with some popular, low-cost 10 GbE NICs and HBA cards.
TrueNAS Scale, by contrast, is based on the current Debian 11 release, which enabled support for expansion cards incompatible with TrueNAS Core, as well as Docker containers.
By default, TrueNAS uses a dark interface theme.

If you want, you can switch to the light theme or create your own.

OMV is tightly integrated with Debian Linux. OMV 4.x runs on Debian 9, the current OMV 5.x uses Debian 10, and OMV 6 (currently in testing) is based on Debian 11.
Only one light theme is available in OMV 4 and 5.

OMV 6.0 introduced a redesigned interface.

Installation, Configuration, and Storage Layout
Installing any of the options described above is fairly straightforward: download the distribution for your target platform, create a bootable drive, and boot from it. However, openmediavault also offers an alternative installation method—on top of an already configured Debian system (you can install OMV 4.x on Debian 9, and OMV 5.x on Debian 10).

Less experienced TrueNAS users may run into difficulties when setting up a multi-disk array. While OMV relies on the familiar Linux mdadm tool to create and manage RAID, in TrueNAS the ZFS stack is both the filesystem and the low-level manager of multi-disk configurations. ZFS doesn’t use the standard RAID levels; instead it offers functional equivalents. The counterpart to RAID 5 is RAID-Z1, and to RAID 6 is RAID-Z2. Z1 and Z2 indicate the redundancy level—the number of disks that can fail without data loss: a RAID-Z1 array can tolerate the failure of any single disk, and RAID-Z2 can tolerate any two.

But that’s just where the complexity begins. A set of disks forms a single vdev (virtual device); one or more vdevs make up a pool (zpool), on top of which you can create one or more datasets (in ZFS terminology). (You can read more about ZFS topology, for example, here.)
Compared to standard mdadm, this setup is harder to grasp, but it offers excellent flexibility. For example, you can create a pool from three disks in a RAID-Z1 vdev, then expand it with another three-disk RAID-Z1 vdev, and the sizes of the original and later-added vdevs don’t even have to match. That’s undeniably convenient and creates an impression of limitless scalability. Unfortunately, it’s only an impression.
As of today, TrueNAS does not support expanding storage at the vdev level. You can grow a pool (zpool) by adding another vdev built from any number of drives in any supported configuration, but you can’t increase the capacity of an existing vdev by adding another drive to it or by swapping in larger drives. Maybe this capability will appear in TrueNAS in a few years, but I wouldn’t expect it any time soon. The challenges of vdev expansion are covered in detail here: ZFS fans, rejoice — RAIDz expansion will be a thing very soon.
Where to install it
All three systems need a separate storage device for installation—a hard drive or SSD—but they’ll also work with a USB flash drive or memory card (if you plan to install OMV on a flash drive or memory card, make sure to install the flashmemory plugin from the omv-extras repository; it moves parts of the filesystem with frequent writes into RAM and synchronizes that data on boot and shutdown).
This approach has pros (data disks can properly enter sleep, and the system won’t spin them up every time it wants to append to a log) and cons (you’ll lose all system settings if the dedicated boot drive fails and you don’t have a backup of the configuration).
By the way, with some effort you can install OMV on the same drive that stores your data. That’s how it was done in builds for single-drive WD My Cloud Home NAS units. There are plenty of pitfalls, though—chief among them, it’s hard to get the drive to enter a proper sleep/spin‑down state.
Compatibility and system requirements
It’s pretty straightforward: TrueNAS needs an Intel-architecture CPU and at least 8 GB of RAM. OpenMediaVault, by contrast, is extremely lightweight; you can install it even on a Raspberry Pi. In my experience, it runs great (and very fast!) even on ARM devices with four Cortex-A53 cores and 512 MB of RAM. You can even install OMV on devices like the WD My Cloud Home (both single- and dual-bay models)!
Why does TrueNAS need so much RAM? The key is real-time (inline) data deduplication. When this feature is enabled, the deduplication tables are kept in memory. ZFS computes checksums for blocks as they’re written, and if it finds a match, it won’t write a new block—just stores a reference instead. Note that inline dedup is quite slow: write performance can drop by 3–5x on a fast pool over 10 GbE. Over 1 GbE, the slowdown may be barely noticeable.
You’ll often see the advice to use TrueNAS with ECC (error-correcting) RAM. Treat it as a recommendation, not a requirement: TrueNAS will run on non‑ECC memory just like any other system. That said, ZFS is very memory‑hungry, and bit flips in RAM can lead to on‑disk data corruption—sometimes fatally. The same caveat applies to other systems, too. If you can use ECC RAM, do it; if not, use what you have.
File System Support
In both editions, TrueNAS stands out for its complete support of all ZFS capabilities—covering both the filesystem and the disk management layer. This includes creating and managing all storage layers (vdev, zpool, dataset), encryption, snapshots and their replication, as well as real-time data deduplication. Other filesystems are supported by TrueNAS only to a limited extent, for example to import data from a drive formatted with such a filesystem.
By default, openmediavault supports the same filesystems as Debian Linux. ext4 is used as the default for data storage. Full list of supported filesystems.
OMV does list BTRFS and ZFS as supported filesystems, but don’t expect too much: BTRFS disks are managed via the command line, and ZFS support is missing a lot of features. In particular, neither filesystem has snapshot or replication support. You can create snapshots manually from the CLI (OMV runs on a full Debian distribution, after all) or even through the web UI as Scheduled Tasks, but it’s still clunkier than a turnkey solution. If you need snapshotting and replication, consider TrueNAS.
Data Encryption
OpenMediaVault doesn’t include built-in encryption, but there’s a plugin available: openmediavault-luksencryption.

TrueNAS supports multiple encryption standards.
First, there’s SED (Self-Encrypting Drive), a hardware encryption feature available on some drive models. It’s covered in detail here.
Secondly, there’s GELI encryption, the de facto standard in FreeBSD. In TrueNAS 12 (both editions), this scheme was replaced with a different one, but previously created encrypted volumes can still be mounted and used.
Finally, the new encryption standard in TrueNAS is native ZFS encryption, explained in detail in the Ars Technica article A quick-start guide to OpenZFS native encryption.

Without delving into the technicalities (which are well documented), native ZFS encryption has a number of advantages over both LUKS and GELI. It lets you run most—if not all—zfs and zpool commands on encrypted disks even when the encryption key hasn’t been provided or is unknown. This includes maintenance operations like data integrity verification, snapshots and their replication, and many other commands. By contrast, if a disk is encrypted with LUKS, you must unlock it with the encryption key before performing similar operations.
This kind of encryption has its downsides, particularly in terms of security. First, even without loading the encryption key, the names and sizes of ZFS filesystems (and other information available via the zfs and zpool commands) can still be listed. However, the names and sizes of encrypted files are not exposed, nor is any other metadata that isn’t obtainable through zfs and zpool commands.
Another kind of data that isn’t covered by native ZFS encryption is the deduplication tables. To be precise, individual data blocks are still encrypted, but analyzing the dedup tables can reveal which blocks on the disk are duplicates. The value of this information to an attacker is questionable, so this aspect of native ZFS encryption isn’t viewed as a critical security issue. That said, when encrypting highly sensitive data, it’s advisable to disable online deduplication.
Finally, there’s the largely theoretical CRIME (Compression Ratio Info-leak Made Easy) vulnerability, which can be exploited in scenarios where data is compressed before it’s encrypted.
Snapshots, Encryption, and Replication
I wrote in detail about snapshots and their replication in the article “NAS on Ryzen: What the Synology DS1621+ can do and why it needs a powerful CPU.” In short, snapshots are a near-ideal backup mechanism: they both protect data from ransomware and let you replicate only the changed blocks (even when the data is encrypted and the decryption key isn’t available). What’s more, bulk renames of files or folders only require syncing filesystem metadata; by contrast, rsync would start deleting and re-copying the renamed files.

ZFS supports snapshots, and TrueNAS offers a user-friendly way to create and replicate them.

OpenMediaVault doesn’t support snapshots in the web UI. You can create them manually from the command line or use the Scheduled Tasks section in the web interface to automate it. Replication is trickier. If you encrypted your data with the LUKS plugin, you’ll need to unlock and mount the encrypted volume to take a snapshot. If you need both snapshots and replication, I recommend looking at TrueNAS. However, if you plan to store backups on external USB drives, OpenMediaVault offers built-in management for those backups—whereas TrueNAS does not.

By the way, rsync is available in TrueNAS as well.

Updates and security patches
Why are regular NAS updates necessary and important? For one, to avoid a repeat of the WD MyBook Live incident, where attackers wiped users’ data en masse. There have been other cases too — for example, numerous vulnerabilities discovered in QNAP devices.
TrueNAS updates are handled by the vendor, iXsystems. Updates are system-wide (monolithic) and released fairly regularly; in-place upgrades for major versions are officially supported (e.g., moving from FreeNAS 11 to TrueNAS CORE 12).

You can migrate from TrueNAS CORE to TrueNAS SCALE; your data will be preserved, but system settings will be lost. Going back the other way can be tricky. When I tested it, TrueNAS SCALE was using a newer OpenZFS. After upgrading the ZFS metadata version (not required), I could no longer use the same dataset in TrueNAS CORE. So if you want to try SCALE but keep the option to roll back to CORE, just don’t upgrade the ZFS metadata (on-disk format/feature flags).

Updates for openmediavault are handled by quite a few parties. Core OMV updates come from the project’s developers. Updates for the Debian packages the system runs on are modular and maintained by the broader community: if a vulnerability is found in a package, there’s a good chance it will be patched before attackers can get their hands on your device.

The Debian version itself won’t be upgraded: OMV 4.x only runs on Debian 9, and OMV 5.x only on Debian 10. From a security standpoint, there isn’t much difference—both Debian 9 and especially Debian 10 will keep receiving component-level updates for a long time. Also, when installing (or updating) certain packages, you may need to pull newer builds of dependencies from alternative repositories.

A major downside of OMV is the lack of an official upgrade path for major releases. You can’t perform an in-place upgrade from OMV 4 to OMV 5 (and OMV 4 builds won’t receive updates). There are community-written guides, but they may or may not work (they didn’t work for me). So if you want to stay on the latest OMV releases, be prepared for a complex and risky migration each year.
Here’s how users describe their experience upgrading OMV from version 4 to 5 (original in German):
The main problem—and OMV’s biggest drawback—is that it doesn’t generate a unified “configuration file” you can use to easily update the OS. This means that with every OMV update you need to:
- Check plugins: confirm that the plugins you use are still available after the upgrade (moving from v4 to v5 removed many plugins in favor of equivalent Docker images).
- Preserve settings: take screenshots or back up the /etc directory, or create a Clonezilla (or similar) image of the system disk—and copy it to a location you can access even without the NAS.
Even better—just grab a spare drive and install the new OS on it. Your data disks, RAID arrays, and ZFS pools are usually detected and mounted automatically during this kind of upgrade (note: SnapRAID and/or mergerfs won’t be auto-detected)!
Another downside of OMV is its modular update model. In six months of running a NAS with OMV, I twice encountered cases where a package update altered settings in specific configuration files, and the device stopped working properly.

We were able to trace exactly which file was modified and how, but we couldn’t identify the specific package. That brings us to the next section: operational stability and the challenges of keeping the device up and running.
Operational Stability
In a perfect world, once configured, a system would run without any intervention. Updates would install automatically and never cause problems. Unfortunately, reality is far from ideal: updates occasionally break things, and even without them a device may eventually need at least some preventive maintenance.
In this context, TrueNAS Core has proven to be the least troublesome. The system is well-polished, and updates—aside from major jumps like 11 to 12—generally don’t cause issues. Once it’s up and running, a TrueNAS box can operate for long periods without any intervention.
TrueNAS Scale is an early beta running on a platform that’s new to the developers. Accordingly, stability isn’t guaranteed—though users haven’t reported any significant issues.
Keeping an OpenMediaVault-based NAS running smoothly may require periodic attention from a skilled administrator. This includes the previously mentioned issues that can crop up after updating certain packages, as well as simple things like the default log rotation settings, which can fill up a partition and leave the NAS accessible only via SSH. The latter is mainly a concern if you’re running OMV from a small-capacity drive; the former—you’ll just have to live with.
Bottom line: if you need stable, hands-off operation, pick TrueNAS Core.
Performance
I didn’t run a head-to-head performance benchmark, but I can say TrueNAS is noticeably heavier than openmediavault. OMV boots lightning-fast even on very low-end hardware (on a WD MyCloud Home it takes about 16 seconds after the hard drive spins up), whereas TrueNAS takes significantly longer to boot even on powerful hardware.
With TrueNAS, many factors can impact read/write performance. For example, enabling inline deduplication can dramatically slow write speeds, and turning on on-the-fly compression often hurts more than it helps with modern, already-compressed data formats. Upgrading RAM to 16 GB or more can help.
OMV is a very lightweight system that runs on any hardware capable of running Debian.
Virtualization and Extensions
All three systems support extensions via purpose-built plugins for each platform. OpenMediaVault also supports additional repositories (for example, omv-extras).

TrueNAS also includes plugins—both official and community-developed.


Every system supports some form of lightweight virtualization. In TrueNAS Core, that’s the jails system, while TrueNAS Scale and OMV support Docker. The latter is arguably more appealing due to the wide variety of available images.
TrueNAS also includes full-fledged virtualization with virtual machines—you can even install Windows, for example.

Wrapping up
Ultimately, all three systems are worth considering. At the same time, choosing between them can be fairly straightforward if you base the decision on your needs and the hardware you have available.
Want to build a NAS on a single-board computer like a Raspberry Pi? OpenMediaVault. Installing on a WD My Cloud Home? Same story. Need to run it on a low-power PC with limited RAM? OMV again. Building a NAS with a single drive or using external disks over USB? Probably OMV once more.
Thinking of turning an old PC with 8 GB or more of RAM into a NAS? TrueNAS is a much better option: go with TrueNAS Core if stability is your top priority, or TrueNAS Scale if you want to experiment or need Docker support.
Need encryption, snapshots, and replication? TrueNAS—no question.
What if all you need is storage for a media library or video archive that gets new files only occasionally but is accessed often? If your priorities are data reliability and quiet operation rather than speed, Unraid or SnapRAID might be a good fit—we’ll talk about them next time.

If you need cloud management, use TrueNAS with TrueCommand.