The openmediavault file system types listed in the OMV 8 docs come to 16: six it can format (ext4, XFS, Btrfs, ext3, JFS, F2FS), nine it can only mount (NTFS, exFAT, vfat, msdos, HFS+, UDF, ISO 9660, UFS, umsdos), and ZFS, which needs an omv-extras plugin. For a data disk, pick ext4 unless you specifically want checksums and snapshots.
Most options carry a catch the web UI doesn’t mention: Btrfs features that live only on the command line, XFS volumes that grow but won’t realistically shrink, and mount options OMV rewrites whenever it regenerates fstab. How to combine several disks is a separate decision, covered in planning OMV disks, filesystems and shares.
Which file systems can OpenMediaVault 8 format and mount?
OMV 8 formats btrfs, ext3, ext4, f2fs, jfs and xfs from Storage > File Systems, and mounts all of those plus exfat, hfsplus, iso9660, msdos, ntfs, udf, ufs, umsdos and vfat. ZFS has neither format nor mount support in the core because it comes from a third-party plugin, per the OMV 8 filesystems documentation.
The mount options below come from OMV’s filesystem environment variables page. The last column is editorial judgment, not documentation.
| Type | Format in web UI | Mount | OMV default mount options | Realistic use |
|---|---|---|---|---|
| ext4 | Yes | Yes | defaults, nofail, user_xattr, journaled user/group quota | Default data disk |
| xfs | Yes | Yes | defaults, nofail, usrquota, grpquota | Fine if you never shrink |
| btrfs | Yes, single device only | Yes | defaults, nofail | Checksums and snapshots, plus CLI work |
| f2fs | Yes | Yes | Not listed | Flash media, niche |
| ext3 | Yes | Yes | Same as ext4 | Legacy, skip |
| jfs | Yes | Yes | defaults, nofail, usrquota, grpquota | Legacy, skip |
| ntfs, vfat, msdos, exfat | No | Yes | defaults, nofail (ntfs, vfat) | Copying data off old disks |
| hfsplus | No | Yes | defaults, nofail, force | Copying data off old Mac disks |
| iso9660, udf | No | Yes | ro | Optical media and disc images |
| ufs, umsdos | No | Yes | Not listed | Rare legacy disks |
| zfs | No (core) | No (core) | Managed by the plugin | Multi-disk pools on amd64 |
Which file system should you pick for a data disk?
Use ext4 for most single data disks, including every member of a mergerfs pool. XFS is fine if you’ll never shrink the volume. Btrfs makes sense when you want checksums and snapshots and don’t mind some shell work. ZFS fits a multi-disk pool on amd64, if you accept the plugin and kernel setup.
The boring answer wins because the filesystem is rarely what fails on a home NAS. Disks die, USB enclosures drop off the bus, and the backup turns out to be months old. ext4 doesn’t checksum file contents, which is a real gap, but an off-box backup covers more failures than any filesystem switch. If integrity is the actual goal, go all the way to Btrfs or ZFS.
ext4: the default for good reasons
OMV mounts ext4 with defaults,nofail,user_xattr plus journaled user and group quotas (usrjquota=aquota.user,grpjquota=aquota.group,jqfmt=vfsv0). Extended attributes and quotas work out of the box, and nofail means a missing USB disk won’t stop a headless box in a closet from booting.
The resize2fs manual says it can expand a mounted ext3 or ext4 filesystem and can enlarge or shrink an unmounted one. That two-way flexibility is ext4’s quiet advantage over XFS. OMV’s Resize button only expands, after you’ve grown a partition or an mdadm array. Shrinking is a manual, unmounted job you do after a backup.
XFS: fine, until you want it smaller
XFS gets defaults,nofail,usrquota,grpquota from OMV, so quotas work there too, and the xfs_growfs manual notes that “the filesystem must be mounted to be grown.”
Shrinking is the catch. The same manual only documents shrinking the last allocation group without removing it, which is not what anyone means when they want half a disk back. Treat XFS as one-way: reclaiming space means copying everything off and reformatting. If you already know and like xfs_repair, it’s otherwise a fine choice.
Btrfs: checksums included, half the features outside the UI
OMV 8 creates Btrfs filesystems in the web interface, but its documentation is blunt: “Creating multi device filesystems is not supported in the web interface.” Devices get added from the CLI. Snapshots and subvolumes don’t appear in the UI at all, and extra subvolumes must be mounted outside OMV’s fstab block or added as mntent entries by hand.
Profile choice matters. The upstream Btrfs feature status page rates RAID1, RAID10, single and DUP as OK for stability, and RAID5/6 as unstable, testing only, with known severe problems. Scrub, send/receive and compression are rated OK for stability. Quota groups are “mostly OK”, with a warning that many snapshots slow down balance.
OMV mounts Btrfs with only defaults,nofail, so compression stays off unless you add compress=zstd through the environment variable covered below. Btrfs is worth it if you’ll learn btrfs scrub and btrfs subvolume anyway. If you want snapshots to appear in a web UI, you’ll be disappointed.
ZFS: the plugin route, amd64 only
ZFS isn’t a core OMV file system type; the docs say it “requires the use of a third party plugin provided by omv-extras.” The omv-extras ZFS guide strongly recommends installing the Kernel plugin and the Proxmox kernel first, since that kernel ships prebuilt ZFS modules. It warns that a Debian backports kernel can lose those modules across upgrades, “causing pools to become inaccessible.” The omv-extras plugin guide explains the install order.
ZFS on Linux isn’t supported on 32-bit or ARM boards such as the Raspberry Pi. On memory the guide is calmer than forum folklore: 4 to 8 GB is “perfectly fine” for a home NAS, because the ARC read cache releases RAM when other processes need it, and ECC is desirable rather than required. The OMV hardware requirements guide sizes the rest of the box.
The real cost is planning. Redundancy lives per vdev, and a lost vdev loses the pool. A mirror can’t become RAIDZ, RAIDZ1 can’t become RAIDZ2, RAIDZ expansion is slow and one disk at a time, and adding a single-disk vdev turns a redundant pool into a stripe. If ZFS is the whole point of the build, read FreeNAS vs OpenMediaVault before committing.
F2FS, JFS and ext3: the ones you can skip
The kernel F2FS documentation describes it as a log-structured filesystem for NAND flash storage, which makes it tempting for SD cards and flash drives. On a data disk holding the only copy of something, a smaller user base means fewer forum threads when it breaks. JFS and ext3 are there mostly for compatibility and do nothing ext4 doesn’t, so don’t start a new disk on either.
What about NTFS, exFAT and other mount-only types?
OMV 8 mounts NTFS, exFAT, FAT (vfat and msdos) and HFS+ disks but cannot format them, so use them to get data onto the NAS, not to keep it there. Mount the old disk, copy its contents to ext4, XFS or Btrfs, then wipe and reuse it.
FAT and exFAT have nowhere to store Linux owners and permissions, which the privileges and ACLs in OMV’s shared folder setup rely on. HFS+ deserves a specific warning: OMV mounts it with force, which the kernel HFS+ documentation says forces write access to journaled or locked volumes, “use at your own risk.” Copy off, don’t write back. ISO 9660 and UDF mount read-only.
How do you change mount options without OMV overwriting them?
Set an OMV_FSTAB_MNTOPS_* environment variable, then redeploy. OMV generates /etc/fstab from its config database, and edits inside the openmediavault block are overwritten the next time omv-salt deploy run fstab runs. The advanced settings page documents omv-env, which stores values in /etc/default/openmediavault. Adding noatime to ext4 means restating the full default string:
omv-env set -- OMV_FSTAB_MNTOPS_EXT4 "defaults,nofail,noatime,user_xattr,usrjquota=aquota.user,grpjquota=aquota.group,jqfmt=vfsv0"
monit restart omv-engined
omv-salt stage run prepare
omv-salt stage run deployOnly new mounts inherit the variable. For filesystems already mounted, the docs have you edit that entry’s <opts> line in /etc/openmediavault/config.xml, run omv-salt deploy run fstab, reboot and check /proc/mounts. Back up config.xml first.
Two more traps on that page. Disks mounted from the shell aren’t registered in OMV’s database, so they never appear when you create a shared folder. And Delete runs wipefs -a, stripping filesystem, RAID and partition-table signatures. It only unlocks after Unmount, which only unlocks once every shared folder on the filesystem is gone.
FAQ
does openmediavault support zfs
Yes, but not in the core install. ZFS comes from the openmediavault-zfs plugin in omv-extras, and the omv-extras guide recommends installing the Kernel plugin and switching to the Proxmox kernel first, because it ships prebuilt ZFS modules. It only works on 64-bit amd64 systems, not on a Raspberry Pi or other ARM boards.
is ext4 or xfs better for openmediavault
For most home NAS disks, ext4, mainly because it can be shrunk offline and XFS effectively cannot. OMV 8 formats both, gives both user and group quotas in its default mount options, and neither one checksums file data. If you already know the XFS tools and never resize, it works just as well.
does openmediavault support btrfs raid
Partly: OMV 8 creates single-device Btrfs filesystems in the web interface, but multi-device Btrfs, including RAID1, has to be built from the command line. The upstream Btrfs status page rates RAID1 and RAID10 as stable and RAID5/6 as unstable, so avoid the parity profiles for anything you care about.
what file system should i use for openmediavault on raspberry pi
ext4 on a USB-attached SSD or hard drive is the sensible choice for a Raspberry Pi running OMV. ZFS is off the table because the omv-extras ZFS plugin does not support ARM boards, and Btrfs works but leaves snapshots and multi-device setup to the command line, which is a lot of ceremony for a Pi.
