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
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 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.
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.
