If you've been running Proxmox VE for a while, you've probably hit the point where you want somewhere central to dump files. Backups, ISOs, media, documents — it all needs a home, and scattering it across VM disks isn't a great plan. This is where OpenMediaVault comes in. It's a free, Debian-based NAS operating system, and it runs great inside a Proxmox VM.

This guide walks you through the whole thing: creating the VM, installing OpenMediaVault 8, attaching storage, and getting your first network share working. You don't need any prior NAS experience. If you can install a Linux VM in Proxmox, you can do this.

What You Will Learn

  • What OpenMediaVault actually is and how it's different from just sharing a folder from Proxmox itself
  • How to create a properly sized VM for it in Proxmox VE 9.x
  • How to attach extra virtual disks so OMV has real storage to manage
  • How to run through the OpenMediaVault 8 installer
  • How to log in to the web interface and set up your first SMB share
  • The mistakes that trip up almost everyone on their first try

What Is This Feature?

OpenMediaVault is a network-attached storage (NAS) platform built on top of Debian Linux. Instead of SSHing into a server and editing Samba config files by hand, you manage everything — users, shared folders, disks, permissions — through a web browser. It's the same idea behind appliances like Synology or QNAP, except it's free, open source, and you're running it on your own hardware.

Under the hood it's just Debian with a management layer (called omv-engined) and a plugin system on top. That matters more than it sounds like it should: because it's plain Debian, you can still SSH in and troubleshoot it like any other Linux box when something goes sideways.

Running it as a Proxmox VM rather than on bare metal means you get snapshots, easy backups of the whole NAS config, and the ability to move it to another physical host later without touching hardware. You lose a little raw disk performance compared to bare metal, but for most homelab and small office setups, you won't notice.

Why Would You Use It?

The honest answer: because you need somewhere to put files, and you don't want to manage that by hand. A few concrete reasons people reach for OMV specifically:

  • It's light. OMV runs comfortably with 1-2 GB of RAM. TrueNAS Scale, by comparison, really wants 8 GB or more before it feels happy. If your Proxmox host is a small mini PC with 16 GB total, that difference matters.
  • It uses standard Linux storage. Plain ext4, XFS, or software RAID via mdadm — no learning curve if you already know Linux. ZFS is available too, but it's optional rather than the whole point.
  • The plugin ecosystem covers the basics well. SMB/CIFS, NFS, FTP, rsync, and Docker (through the omv-extras plugin) cover almost everything a homelab needs.

If you're already deep into ZFS and want snapshots, replication, and self-healing storage as the main feature, TrueNAS Scale is worth a look too — that's a separate comparison. This guide is about getting OMV running well, which is the better starting point if you just want simple, reliable file sharing without a steep learning curve.

Prerequisites

  • A working Proxmox VE 9.x host (this also works fine on 8.x — the process barely changes)
  • At least 20 GB of free storage for the VM's boot disk, plus however much you want for actual file storage
  • A couple of GB of free RAM to spare for the VM (2 GB minimum, 4 GB if you plan to run Docker containers on it later)
  • Internet access from the VM, since the installer pulls a few packages during setup
  • About 20-25 minutes, most of which is the installer copying files

Step-by-Step Tutorial

Step 1: Download the OpenMediaVault ISO

Grab the current OpenMediaVault ISO (version 8.x at the time of writing) from the official openmediavault.org downloads page. It's roughly 700 MB. Once you have it, upload it to Proxmox the same way you would any other install image: go to your storage (usually local), open the ISO Images tab, and click Upload.

If your Proxmox host doesn't have a browser handy, you can also download it directly on the host and skip the upload step:

cd /var/lib/vz/template/iso
wget https://sourceforge.net/projects/openmediavault/files/latest/download -O openmediavault-8-amd64.iso

Step 2: Create the VM

Click Create VM in the top right corner. A few settings actually matter here, so don't just click through on defaults:

  • OS tab: select the OMV ISO you just uploaded, and set the guest OS type to Linux, version 6.x - 2.6 Kernel.
  • System tab: leave BIOS as Default (SeaBIOS) unless you specifically need UEFI. Enable the Qemu Agent checkbox — it's harmless to leave off, but useful for clean shutdowns later.
  • Disks tab: set the bus to VirtIO SCSI single, and size the boot disk to at least 20 GB. This disk is just for the OS — it's not where your files live.
  • CPU tab: 2 cores is plenty to start. You can bump this later without reinstalling anything.
  • Memory tab: 2048 MB minimum. If you plan on running Docker containers through OMV-Extras later, give it 4096 MB instead.
  • Network tab: model VirtIO (paravirtualized), bridged to vmbr0 (or whatever your main bridge is called).

Step 3: Attach a second virtual disk for your actual storage

This is the step people skip and then get confused later. OMV needs a separate disk to format and manage as shared storage — you don't want it touching the boot disk.

With the VM selected, go to Hardware → Add → Hard Disk. Pick your storage location, set the size to whatever you actually need (500 GB, 2 TB, whatever fits your pool), keep the bus as VirtIO SCSI, and confirm. You can also add more than one disk here if you're planning to use software RAID inside OMV.

If you'd rather pass through a real physical disk instead of a virtual one — say, an actual spinning hard drive you want OMV to have direct, unabstracted access to — you can do that from the Proxmox shell instead of the GUI:

qm set 100 -scsi1 /dev/disk/by-id/ata-WDC_WD40EFRX-XXXXXX

Replace 100 with your VM's ID and the disk-by-id path with your actual drive (find it with ls /dev/disk/by-id/). Passing the real disk through means OMV sees the true drive, including its S.M.A.R.T. health data — something a virtual disk can't give you.

Step 4: Run the installer

Start the VM and open its console. The OMV 8 installer is text-based and about as minimal as it gets — a handful of screens for language, keyboard layout, hostname, and root password. When it asks which disk to install to, make sure you pick the small boot disk, not the storage disk you added in Step 3. It's easy to get this backwards if you weren't paying attention to disk sizes.

The installer partitions the disk, copies the base system, and installs the OMV packages automatically. This takes somewhere around 8-10 minutes depending on your host's disk speed. It reboots on its own when finished — no prompt, no confirmation, it just restarts.

Step 5: Log in to the web interface

After the reboot, the VM's console shows a login prompt with an IP address. Open that address in a browser from your regular computer — plain HTTP, port 80, nothing fancy needed. Log in with the default credentials:

  • Username: admin
  • Password: openmediavault

Change that password immediately. Go to the top-right user menu, choose Change Password, and set something real. Leaving the default in place on anything reachable from your network is asking for trouble.

Step 6: Set up your first shared folder

Now for the part you actually installed this for. In the OMV interface:

  1. Go to Storage → File Systems, select your second disk, and format it (ext4 is the safe default if you're not sure).
  2. Go to Storage → Shared Folders, click Add, give it a name like "media" or "backups," and point it at the file system you just created.
  3. Go to Services → SMB/CIFS, toggle it on, then go to the Shares tab and add your shared folder there.
  4. Apply the pending configuration changes (there's a yellow banner at the top when changes are waiting).

From a Windows machine, you should now be able to browse to \\your-omv-ip\media. On macOS, use Finder's "Connect to Server" with smb://your-omv-ip. On Linux, most file managers handle it the same way through their network browser.

Commands Explained

You'll mostly live in the web UI, but a few command-line tools are worth knowing:

CommandWhat it does
omv-firstaidA text-menu recovery tool built into OMV. Run it from the console if you're locked out of the web UI, need to reset the admin password, or need to fix networking. This one gets you out of trouble more than anything else on this list.
omv-salt deploy run allForces OMV to re-apply all of its configuration to the underlying system. Useful if the web UI says a setting is applied but it doesn't actually seem to be working.
wget -O - https://get.openmediavault.io | sh -The official installer script for adding OMV on top of an existing Debian install, as an alternative to using the ISO. Only run this on a fresh, minimal Debian 13 VM — not on a system you're already using for something else.
qm set <vmid> -scsi1 /dev/disk/by-id/...Run on the Proxmox host, not inside the VM. Attaches a physical disk directly to the VM for passthrough storage.

Common Errors

A few things come up often enough that they're worth flagging before you hit them yourself.

"No root file system defined" during install. This usually means you're pointing the installer at the wrong disk, or it can't see a disk at all because the VM's disk bus doesn't match what the installer expects. Double-check the disk is set to VirtIO SCSI and that VirtIO SCSI single is selected as the controller type on the VM's Disks tab.

Web interface won't load after install. Nine times out of ten this is a networking mismatch — the VM's network model is set to something the OMV kernel doesn't have drivers for, or the bridge isn't actually connected to your LAN. Check the IP shown on the console login screen matches the subnet you expect, and confirm the VM's network device is VirtIO.

Second disk doesn't show up in File Systems. OMV needs to see the raw disk before you can format it. Go to Storage → Disks first and confirm it's listed there. If it's missing entirely, the disk probably wasn't actually attached — go back and check the VM's Hardware tab in Proxmox.

SMB share is visible but asks for credentials that don't work. By default, OMV doesn't automatically give system users SMB access. Go to Access Rights Management → Users, edit the user, and make sure they're actually a member of the group tied to your share's permissions.

Troubleshooting

If something's broken and you can't figure out why from the web UI, drop into the VM's console (or SSH in, since SSH is enabled by default on OMV) and check the actual system logs rather than guessing:

journalctl -u smbd -n 50
journalctl -u openmediavault-engined -n 50

The first shows recent Samba activity — handy for share and permission problems. The second shows OMV's own management daemon, which is where configuration-apply failures usually surface.

If the whole VM feels sluggish, check whether you gave it enough RAM back in Step 2. OMV itself is light, but the Samba and NFS services plus any plugins you enable add up. 2 GB is a floor, not a comfortable long-term number if you're running much beyond basic file sharing.

One thing that catches people out: virtual disks don't report S.M.A.R.T. data the way real drives do. If you're using virtual disks for storage (not passthrough), don't expect the S.M.A.R.T. monitoring page in OMV to show anything useful — that's expected, not a bug. If drive health monitoring actually matters to you, use the passthrough method from Step 3.

Best Practices

  • Never format the boot disk as a shared folder disk, and never store data you care about only on the boot disk — treat it as disposable OS storage.
  • Take a Proxmox snapshot of the VM right after your first successful setup, before you start adding plugins or tweaking permissions. It's a five-second rollback point if you break something later.
  • Back up the OMV configuration itself, separately from your files. Under System → Backup, you can export the full config as a file — keep a copy somewhere off the VM.
  • If you're using virtual disks rather than passthrough, make sure the underlying Proxmox storage itself is backed up or redundant. A virtual disk is only as safe as whatever it sits on.
  • Don't run OMV and a separate Samba server on the same Proxmox host for the same files. Pick one to be the source of truth.

Frequently Asked Questions

Can I run OpenMediaVault in an LXC container instead of a full VM?

Not reliably. OMV expects to manage its own kernel-level storage stack and services, which doesn't play well with the shared-kernel model LXC containers use. Stick with a full VM.

How much storage overhead does running OMV as a VM add compared to bare metal?

In practice, very little for typical home NAS workloads — file transfers over SMB or NFS are mostly limited by your network speed, not the virtualization layer. If you're chasing every last bit of throughput on 10 Gbps networking, passthrough disks and a tuned network setup close most of the gap.

Do I need ZFS to use OpenMediaVault well?

No. OMV works fine with plain ext4 or XFS, and that's genuinely the simpler starting point. ZFS support exists as a plugin if you want snapshots and checksumming later, but it's not required.

What happens if I lose the boot disk but keep the storage disk?

Your files are safe on the storage disk, but you'll need to reinstall OMV and reconfigure shares, users, and permissions from scratch — none of that lives on the data disk. This is exactly why exporting your config backup matters.

Can I install Docker containers on OMV like I would on a regular Debian server?

Yes, through the omv-extras plugin, which adds a Docker/Compose management page to the web UI. It's basically Portainer-lite built into OMV itself.

Conclusion

Getting OpenMediaVault running as a Proxmox VM isn't complicated once you know which disk goes where and which network settings actually matter. The whole process, ISO download included, takes less time than it took to read this guide. From here, the natural next steps are setting up scheduled Proxmox backups of the VM itself, and exploring the omv-extras plugin if you want Docker apps running alongside your file shares.