OpenMediaVault Hardware Requirements and Build Guide

OpenMediaVault 8, codename Synchrony, is a Debian 13 system with a web interface on top of it. The project’s own release table makes that lineage explicit: every major version is pinned to a Debian major version, and version 8 shipped in December 2025 on Debian 13. That one fact settles most hardware questions before they are asked. If Debian 13 boots on the machine and enumerates the disks, OpenMediaVault will run on it.

What the hardware actually decides is not whether the appliance works. It is how much of your attention it demands over the next five years, and whether the parts that fail are the ones you planned for.

What the documentation requires

The project publishes a prerequisites table with four columns: supported, minimal, best, and a separate recommendation. Reading only the “minimal” column is how people end up with a NAS that technically runs and practically annoys them.

Component	Supported	Documented minimum	Documented “best” and recommendation
Storage drives	SSD, HDD, USB and other interfaces	1 disk, any type	best 2 disks, helium HDD
Memory	1 GiB and above, any type	1 GiB	best 4 GiB; recommended 8 GiB or more in dual channel
Network	WiFi, Ethernet, USB adapters	any	best 10 Mb NIC; recommended 1 Gb, or 10 Gb SFP fibre
CPU	ARM, x86, x86-64	32-bit	best 64-bit; recommended Intel dual core or AMD Ryzen
Operating system	Debian GNU/Linux	Debian 13	Debian 13
System drive	HDD, SSD, USB and similar	1 device, 4 GiB	best 2 devices, 120+500 GiB; recommended 120 GB root plus 8 GB swap

Read that network row carefully, because it is the one line in the table that will mislead you. The “best” cell says 10 Mb NIC, which is a leftover from an older edit and is below even the half-duplex parts the same page warns against; the recommendation cell next to it, 1 Gb or 10 Gb, is the figure to plan against. Elsewhere the two columns are consistent, and where they differ the recommendation is the more current of the pair.

The documentation is blunt about the memory line in particular: 4 GiB is the recommendation “for novice administrators”, 8 GiB is described as best practice for basic operations in a default installation, and dual-channel population is called out as a way to improve performance in low-memory installations. The 1 GiB floor is real, but the same page notes it needs expertise to live with.

CPU: less than you think, with two caveats

Currently supported architectures are AMD64, i386, and ARMv7 and ARMv8. The i386 build has not been officially supported since version 6, though the project still publishes it. In practice that means any 64-bit x86 chip from the last decade, or an ARM single-board computer.

Two things move the CPU requirement upward. The first is encryption: full-disk encryption on the data pool is done in software, so throughput tracks the AES performance of the processor. The second is containers. A NAS that also runs a media transcoder, a photo library indexer and a download client is no longer a file server with a spare core, and the container workload, not the file sharing, sets the CPU budget.

If the machine is only serving SMB and NFS, a modern dual-core chip is not the bottleneck. The disks and the network card are.

Memory: the number that changes with the filesystem

The 4 to 8 GiB guidance in the documentation assumes a conventional filesystem such as ext4 or XFS. Choosing ZFS moves the goalposts, because ZFS caches aggressively in RAM by design.

The OpenZFS FAQ recommends a minimum of 2 GB of memory for ZFS and says 8 GB or more gives the best performance, with more strongly recommended when compression is enabled. Deduplication is a separate and much larger commitment, and the OpenZFS workload tuning guide puts a number on it: the deduplication table holds one entry per unique block in the pool, each entry costs slightly more than 320 bytes of memory, and if the table does not stay cached every miss becomes a random read from disk. Dedup is almost never the right choice on a home NAS, and that arithmetic is why.

On ECC, the FAQ is worth quoting for its restraint. ECC memory “isn’t really a requirement, but it’s highly recommended”, because without it rare bit flips from cosmic rays or failing modules can go undetected. It then acknowledges the practical problem: consumer hardware often does not support ECC, and when it does it costs more, so for home users the extra safety may not justify the price. That is a considered position, not a slogan, and it is a better guide than either of the absolutist arguments you will find in forums.

For planning capacity and parity overhead before committing to a layout, the OpenMediaVault Array and ZFS Sizer on this site works the raw-to-usable arithmetic for a given drive count and protection level.

The system drive is not a data drive

The documentation states the rule plainly: the system drive cannot officially be used for shared resources or as a user data drive, and the data drives cannot be the same devices as the system drives. This is the single most common planning mistake, and it is expensive to undo because it turns a reversible decision into a data migration.

The recommendation is a device with roughly a 120 GB root partition and 8 GB of swap. That is generous for what OpenMediaVault itself needs, and the headroom is the point: package upgrades, logs, container images and plugin state all land there.

Cheap USB thumb drives are a popular system disk and a poor one. The system writes logs continuously, and flash without wear levelling worth the name has a finite number of writes. A small SATA SSD, an M.2 device, or a disk-on-module is the low-drama choice. Whatever you pick, keep a copy of the configuration file and a written record of the disk layout, because rebuilding the appliance from that pair is quick.

Data drives: CMR, SMR, and how SMART reaches the disk

Two hardware details in the prerequisites page do more damage when ignored than anything else on it.

The first is recording technology. For RAID, SnapRAID or mergerfs setups the documentation says to prefer CMR drives over SMR, because SMR drives can stall during rebuilds and parity sync, and the recording technology is usually not obvious from the model number. A drive that behaves acceptably during normal use and then crawls during the one operation that is protecting your data is the worst possible failure mode. Check the model against a published CMR/SMR list before buying, not after.

The second is monitoring. OpenMediaVault only supports SMART for disks connected to a host bus adapter in pass-through mode. Put drives behind a RAID controller that hides them, or behind a USB bridge that does not forward the commands, and the health data the appliance depends on simply is not there. Configure SMART scheduled tests and notification email on day one; the first sign of a failing disk should be an email, not a missing file.

On drive selection itself, the useful public data is fleet data. Backblaze publishes per-model annualized failure rates from its own drive population every quarter. It is not a controlled study and the model mix reflects what a cloud storage company buys, but it is a far better input than an aggregate star rating on a retail page.

Controllers, and the USB trap

Onboard SATA ports are the simplest answer and they pass SMART through cleanly. When the board runs out of ports, an HBA flashed to IT mode presents drives individually to the operating system, which is exactly what OpenMediaVault wants.

USB drive enclosures are where builds go wrong. Multi-bay USB enclosures are known for dropping drives under sustained load, and a drive that vanishes mid-write is indistinguishable from a failure to the array above it. USB is fine for a backup target that is attached on a schedule. It is a poor foundation for a live array.

Network: where a 1 GbE build stops

The documentation puts it in one line: NAS write speed to storage is limited to the speed of the network interface, and to the speed of the network itself. It also recommends full-duplex NICs, noting that half-duplex parts typically offer 10/100 Mbit and that storage drives far exceed those speeds.

The arithmetic is worth doing once. A 1 Gbit/s link carries 125 MB/s before any protocol overhead, and framing plus TCP and SMB headers take a slice off that, which is why a healthy gigabit transfer settles somewhere in the low 110s of MB/s. A single modern hard disk can sustain more than that on sequential reads, and an SSD can saturate the link several times over. On a gigabit network the wire, not the array, is the ceiling.

Moving past it means 2.5 GbE, which is now common on consumer boards, or 10 GbE, which usually means an add-in card. The Intel X550-T2 is the conservative pick for 10GBASE-T over copper: it is a genuine Intel part with mainline driver support, which matters more on a Debian base than raw specification. It also runs warm and expects airflow, so it belongs in a chassis with a fan path across the slot, not in a sealed mini-ITX box.

If shares feel slow and the network is already fast enough, the bottleneck is elsewhere. Slow SMB transfers on OpenMediaVault walks the layers in the order that isolates the cause.

Power, because the machine never turns off

A NAS is an always-on appliance, so its idle draw is the number that matters, not its peak. Idle draw is set mostly by the platform and the spinning disks, and the difference between a repurposed desktop and a low-power board over a year is large enough to notice on a bill.

This is measurable at the wall rather than estimated from datasheets, which are optimistic. An inline meter such as the Kill A Watt P3 P4400 gets you an actual figure for your build, and knowing the real idle draw is also what makes the decision about spinning disks down rational rather than superstitious.

Three reference builds

	Quiet starter	Balanced home NAS	Container-heavy build
CPU	Low-power dual or quad core	Modern quad core	6+ cores with hardware transcode
Memory	8 GiB	16 GiB, dual channel	32 GiB, dual channel
System drive	120 GB SATA or M.2 SSD	120 GB SATA or M.2 SSD	250 GB M.2 SSD
Data drives	2 CMR disks	4 to 6 CMR disks on onboard SATA	6+ CMR disks on an IT-mode HBA
Filesystem	ext4 or Btrfs	ZFS or union plus parity	ZFS
Network	Onboard 1 GbE	Onboard 2.5 GbE	10 GbE add-in card

The starter build is deliberately unambitious. Its job is to be reliable and boring while you learn where the layers are, and the layout decisions behind it are covered in planning an OpenMediaVault NAS.

Before you buy

Confirm the board’s SATA port count and whether any ports are shared with M.2 slots, because shared lanes silently disable ports. Check every candidate drive model against a CMR/SMR list. Verify the network card has in-tree Debian driver support rather than a vendor blob. Decide the filesystem before the disks arrive, since that decision sets the memory budget. Budget a system disk that is not a thumb drive.

One installation constraint is easy to miss: OpenMediaVault expects a clean Debian target with no prior installation of the packages it manages, port 80 free for its nginx interface, and networking left to netplan. Installation inside LXC or another container solution is explicitly not supported, and virtualization is possible but degrades storage access in ways that depend on the hypervisor.

If you are still choosing between building this and buying an appliance, OpenMediaVault vs TrueNAS vs Synology sets the three approaches against each other on hardware freedom, filesystem, upgrades and what each one costs you when something breaks.