OpenMediaVault NAS Planning: Disks, Filesystems, Shares

OpenMediaVault is a Debian system with a web interface that manages storage services. It does not invent its own storage stack. Underneath the interface everything is standard Linux: block devices, filesystems, Samba, NFS, rsync and systemd. Once you know which layer you are working in, the interface stops feeling arbitrary.

The four layers, in order

Disks are raw block devices. A filesystem is created on a disk or on an array of disks and then mounted. A shared folder is a named directory inside a mounted filesystem, with an owner and permissions. Services such as SMB, NFS or rsync publish shared folders to the network.

The order matters because each layer only sees the one below it. You cannot create a share before a filesystem is mounted, and the services reference shared folders rather than raw paths. Most early confusion comes from trying to skip a step.

Keep the system disk separate

OpenMediaVault installs onto its own device and expects data disks to be dedicated to storage. Giving it a disk you also want to fill with files leaves you fighting the partition layout later. A small dedicated SSD is the simplest choice. Cheap USB flash drives work but they are write-limited and the system writes logs continuously.

The system configuration lives in a single XML file, so a copy of that file plus a list of your disk layout is enough to rebuild the appliance quickly. Take that copy before every significant change.

The documentation puts a size on the system disk too: roughly a 120 GB root partition with 8 GB of swap. What to buy for the rest of the machine, and which parts are worth spending on, is set out in the OpenMediaVault hardware guide.

Choosing how disks are combined

There are several common approaches, and they fail differently.

Independent disks are the simplest. Nothing is striped, so a failure costs you only that disk’s contents, but you manage capacity by hand.

Classic mdadm RAID presents one large volume with redundancy. The tradeoff is that a rebuild after a failure reads every remaining disk, and the array is a single unit to lose.

A union filesystem with separate parity treats disks individually while still allowing recovery of a failed drive. Files stay readable on their own disk, mixed drive sizes are allowed, but parity is computed on a schedule rather than continuously, so recent changes are not covered.

Checksumming filesystems add snapshots and detection of silent corruption, at the cost of more memory and a stricter expansion model.

Pick based on the failure behaviour you want to live with, not on capacity efficiency.

One caveat applies to every option above: the documentation recommends CMR drives over SMR for RAID, SnapRAID and mergerfs setups, because SMR drives can stall during a rebuild or a parity sync and the recording technology is rarely obvious from the model number.

Once you have a candidate layout, the OpenMediaVault Array and ZFS Sizer turns a drive count and a protection level into raw, usable and parity figures, which is usually the point where a plan either survives contact with the capacity you actually need or gets revised. If you are still deciding whether to build at all, OpenMediaVault vs TrueNAS vs Synology compares this approach against the two obvious alternatives.

Redundancy is not a backup

Redundancy covers exactly one scenario: a disk stops working. It does not cover accidental deletion, ransomware, a filesystem going bad, a power event that takes several drives, or the machine being stolen. Keep at least one copy of anything you care about outside the NAS, and schedule it rather than doing it by hand.

Permissions

Two permission layers apply at once: the underlying filesystem ownership and ACL on the shared folder, and the options set on the SMB or NFS share itself. The most maintainable model is a single group for everyone who should have access, group ownership on the shared folders, and per-share exceptions only where genuinely needed. Enabling guest access is easy and awkward to reverse once clients have cached it.

Permissions are also worth getting right before you start tuning anything for speed, because a share that behaves oddly for one user is a permissions problem wearing a performance costume. When the shares are correct and transfers are still slow, slow SMB transfers on OpenMediaVault works down the layers in the order that isolates the real cause.

Common mistakes

Building an array on consumer USB enclosures, which drop drives under load. Leaving SMART monitoring and notification email unconfigured, so the first sign of a failing disk is missing data. Forgetting to apply pending configuration changes in the web interface. Storing container data on the OS disk. Copying data in before deciding on the final filesystem layout, which turns a reversible decision into a migration.