OpenMediaVault 8 can create ext4, XFS and Btrfs filesystems, plus ext3, JFS and F2FS. It can only mount NTFS, exFAT, FAT and HFS+ disks, and it gets ZFS through two omv-extras plugins. For a single data disk, ext4 keeps the plan small; mismatched disks suit mergerfs plus SnapRAID; Btrfs or ZFS fit when checksums and snapshots are the point, with ZFS costing the most memory. The sections below cover how each option fails and how filesystems, shared folders and SMB shares stack up.
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.
OpenMediaVault filesystem vs shared folder vs SMB share
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.
Keep a copy of /etc/openmediavault/config.xml and a record of your disk layout before significant changes. The OMV FAQ describes this file as a configuration reference, not a ready-made restore mechanism. Back up the system and the shared data separately.
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.
For a board-based installation, the OpenMediaVault on a Raspberry Pi guide takes this plan through OS installation, a separate USB data disk and the first SMB share. Use its power and storage checklist before choosing an enclosure.
Choosing how disks are combined
Start with what OMV can do with each filesystem. Per the OMV 8 filesystems documentation, it formats some, only mounts others, and leaves ZFS to plugins. Memory guidance comes from the prerequisites page: a 1 GiB minimum, with 4 GiB recommended.
| File system | What OMV 8 does with it | Memory to budget | How it fails |
|---|---|---|---|
| ext4 | Creates and mounts | OMV’s own guidance is enough | On its own disk, a failure loses only that disk’s files; no data checksums, so silent corruption goes unnoticed |
| XFS | Creates and mounts | OMV’s own guidance is enough | Same as ext4: per-disk loss, no data checksums |
| Btrfs | Creates and mounts | OMV’s own guidance is enough | Checksums detect silent corruption; snapshots available |
| ext3, JFS, F2FS | Creates and mounts | OMV’s own guidance is enough | No data checksums; no reason to prefer them over ext4 for a new data disk |
| NTFS, exFAT, FAT, HFS+ | Mounts only; cannot format | Not applicable | Fine for copying data off an old disk; treat as a migration step, not the final layout |
| ZFS | omv-extras Kernel plugin, then the ZFS plugin | The most of any option here | Checksums detect silent corruption; the pool is one unit to plan and expand |
Two ZFS details matter before you buy. The omv-extras ZFS guide has you install the Kernel plugin and the Proxmox kernel, reboot, then install the ZFS plugin, and it rules out 32-bit and ARM boards such as the Raspberry Pi. The omv-extras plugin guide walks through that order.
Then decide how the disks combine. 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, which on OMV means the mergerfs and SnapRAID plugins, 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, Btrfs on its own or ZFS through the plugins, add snapshots and detection of silent corruption. ZFS costs the most memory and has the 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.
mergerfs and SnapRAID setup on OMV 8, in order
The OMV 8 pages for both plugins are still marked in progress and point to the OMV 7 guides, which give this sequence:
- Format and mount every data disk and the parity disk under Storage > File Systems. The SnapRAID plugin guide says the parity drive must be the same size as, or larger than, the largest data drive.
- Under Storage > mergerfs, create a pool from the data filesystems only. The mergerfs plugin guide shows “Existing Path - Most Free Space” as the preset create policy. Parity drives stay reserved for SnapRAID.
- Create shared folders on the pool under Storage > Shared Folders.
- Under Services > SnapRAID, create an array, add each data disk with Content and Data ticked, and add the parity disk with only Parity ticked.
- Run the first Sync from the Tools menu.
- In Settings, set the diff thresholds, enable notifications and scrub, then use Schedule Diff to run diff, sync and scrub on a timer.
Check the capacity, then the platform
Once you have a candidate layout, the OpenMediaVault RAID Capacity Calculator 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 compares this approach against ZFS-first storage and a Synology appliance.
Why a mounted disk is missing from shared folders
Mount the filesystem through Storage > File Systems before creating the shared folder. The filesystem documentation explains that OMV records the mount in its configuration database; mounting only at the command line does not create that record. Check that the intended data filesystem appears in OMV before creating another filesystem on the disk. Creating a filesystem is a destructive operation, not a way to register an existing mount.
Once the filesystem is listed, how to create a shared folder in OpenMediaVault takes it through the shared folder form, privileges and the SMB share.
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 filesystem ownership and ACL on the shared folder, and the options on the SMB or NFS share itself. Plan for one group that gets access and per-share exceptions only where genuinely needed. The shared folder guide covers the permission modes, privileges and ACLs, and why guest access is awkward to reverse.
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.
