Update OpenMediaVault Without Losing Data

Update OpenMediaVault Without Losing Data: The Complete Safe Guide

If you’ve been putting off updating your NAS because you’re afraid of what might happen to your files, this guide is for you. The goal here is simple: show you how to update OpenMediaVault without losing data — whether you’re applying routine package updates or jumping to a brand-new major version like OMV 8 (Synchrony). Let’s make it boring and safe, the way home server updates should be. 🛡️

What Actually Gets Updated — and What Doesn’t

Before touching a single command, it’s worth understanding the architecture. OpenMediaVault separates the OS layer (your system drive, where OMV itself lives) from your storage drives (where your actual data lives — RAID arrays, individual disks, shared folders).

When you update OpenMediaVault without losing data, you’re updating packages on the OS drive only. Your data drives are never touched by the update process. This means:

✅ Your shared folders remain intact
✅ Your RAID/mergerfs arrays are unaffected
✅ Your Docker volumes and containers persist (on separate drives)
⚠️ Your OMV configuration lives on the OS drive — back that up!

For context, I’m running this on a compact mini NAS box and the same steps apply to any AMD64 or ARM64 system. 🖥️

Prerequisites ✅ — Before You Update OpenMediaVault Without Losing Data

To update OpenMediaVault without losing data, a few things need to be in place first. Confirm the following:

You have SSH access to the server (or physical access with keyboard + monitor)
You know your current OMV version — check it via SSH: dpkg -l openmediavault | grep " openmediavault "
You have a UPS or reliable power — never update during potential power cuts
You have at least 2GB free space on your OS drive (df -h /)

🔐 Back Up Your OMV Configuration

This is the most important step before you update OpenMediaVault without losing data. OMV stores its entire configuration in one file: /etc/openmediavault/config.xml — shares, users, services, network settings, everything.

Back it up via SSH:

# Copy the config file to your home directory
# - if logged in as pi:   saves to /home/pi/
# - if logged in as root: saves to /root/
sudo cp /etc/openmediavault/config.xml ~/omv-config-backup-$(date +%Y%m%d).xml

# Make the file readable so you can scp it as a non-root user
sudo chmod 644 ~/omv-config-backup-$(date +%Y%m%d).xml

The file will be saved in your home directory — verify with:

ls -la ~/omv-config-backup-*.xml

Then copy that file off the server to your PC — run this on your local machine:

# If logged in as pi:
scp pi@<omv-ip>:~/omv-config-backup-*.xml ./

# If logged in as root:
scp root@<omv-ip>:~/omv-config-backup-*.xml ./

⚠️ Critical: If something breaks after a major upgrade, this file is how you restore your shares and settings without reconfiguring everything from scratch.

📋 Check Your Installed Plugins Before Upgrading

This is the step the upgrade dialog is warning you about. Run this to see what you have installed:

dpkg -l | grep openmediavault

Then cross-reference your list against the official OMV 8 plugin availability table on the omv-extras wiki. It shows every plugin and whether it’s available for OMV 8.

⚠️ Critical: If a plugin you depend on is not yet available for OMV 8, do not upgrade yet — wait until it’s ported. Upgrading without checking this can leave you without functionality that’s hard to replace.

Core OMV plugins (like openmediavault-md, openmediavault-lvm2, openmediavault-sharerootfs) are maintained by the core team and are available for OMV 8. Third-party plugins from omv-extras vary — always check the table first.

Step 1: Minor Updates (Within the Same Major Version)

This covers routine updates — security patches, bug fixes, and new features within OMV 6.x, 7.x, or 8.x. You can update OpenMediaVault without losing data this way with zero drama.

Option A — Via the Web UI

Go to System → Update Management → Updates. OMV checks for available packages daily via cron-apt. If updates are listed:

Click Check to refresh the package list
Review the changelog for any plugin-specific warnings (some plugins show migration notices here — read them!)
Click Install to apply all updates

The system will apply updates and may ask you to reboot. Always reboot when prompted. 🔄

Option B — Via the CLI (SSH)

This is the fastest way to update OpenMediaVault without losing data from the command line:

# Update package index and upgrade all packages
sudo apt update && sudo apt upgrade -y

After it finishes:

# Reboot to load the new kernel (if updated)
reboot

ℹ️ Security updates are applied automatically in the background by default. You only see non-security updates in the Update Management UI.

Step 2: Update OpenMediaVault Without Losing Data — Major Version Upgrade

This section covers jumping between major versions: OMV 6 → OMV 7, or OMV 7 → OMV 8. The same core principle applies — you update OpenMediaVault without losing data because your storage drives are never part of the OS upgrade path. As of December 2025, OMV 8 “Synchrony” (based on Debian 13 Trixie) is the latest major release.

⚠️ Architecture check first! OMV 8 only supports AMD64 and ARM64 architectures. If you’re on an older 32-bit board (armhf, armel, i386), you cannot upgrade to OMV 8. Intel N100, Intel/AMD x86-64 machines, and Raspberry Pi 4/5 are all fine.

🔧 Pre-Upgrade Checklist

Apply all pending minor updates first — run sudo apt update && sudo apt upgrade -y as described in Step 1 above, then reboot before proceeding.
Stop non-critical Docker containers (optional but safer — gives you a clean upgrade state):

docker ps -q | xargs --no-run-if-empty docker stop

Confirm your backup is done (see Prerequisites above)
Open a tmux session — the upgrade takes 10–30 minutes and you don’t want SSH timeout to interrupt it mid-run:

# Install tmux if not present
sudo apt-get install -y tmux

# Start a persistent session
tmux new -s upgrade

🚀 Run the Major Upgrade

With your tmux session open and all pre-checks done, run:

sudo omv-release-upgrade

This command:

Updates OMV package repositories to the new release channel (e.g., synchrony for OMV 8)
Runs a full Debian distribution upgrade
Migrates OMV configuration to the new format
Handles dependency resolution automatically

⚠️ Do not interrupt this process. If your SSH client disconnects, reattach with tmux attach -t upgrade. Interrupting mid-upgrade can leave the package system in a broken state.

The process will ask a few interactive questions (e.g., about config file changes from packages). When in doubt, keep the currently installed version unless you know what the change does.

After it completes:

# Reboot to boot into the new kernel
reboot

After reboot, confirm the upgrade succeeded:

dpkg -l openmediavault | grep " openmediavault "
# Should show version 8.x.x in the output

Step 3: Post-Upgrade Verification 🔍

You’ve successfully managed to update OpenMediaVault without losing data — now let’s confirm everything came through cleanly:

Check your storage:

# Verify all drives are visible and healthy
lsblk
cat /proc/mdstat  # if using software RAID

Check services:

In the OMV web UI, navigate to Services and confirm SMB/NFS/SSH are active. If a service shows as inactive despite being enabled, go to System → Apply Changes to re-trigger the Salt configuration.

Check Docker (if using omv-extras Compose plugin):

# Restart all previously stopped containers
docker compose -f /path/to/compose.yml up -d

If the Compose plugin itself is missing after a major upgrade, reinstall it via System → Plugins in the web UI.

Verify your shared folders:

Browse to Storage → Shared Folders and confirm your shares are still listed. Then test access from a client machine over SMB or NFS.

Troubleshooting 🔧

These are the most common issues you may hit when you update OpenMediaVault without losing data. None of them affect your storage — they’re all OS-layer problems.

❌ Error: http://packages.openmediavault.org/public ... does not have a Release file

This is the most likely error you’ll hit. The packages.openmediavault.org server returns 404 for older release names (sandworm, synchrony). The fix is to comment out that line from your apt sources.

First, check what’s in the file:

cat /etc/apt/sources.list.d/openmediavault.list

If you see a line starting with deb that points to http://packages.openmediavault.org/public, comment it out:

# For the sandworm repo (OMV 7 sources):
sudo sed -i 's|^deb \[signed-by=/usr/share/keyrings/openmediavault-archive-keyring.gpg\] http://packages.openmediavault.org/public/ sandworm main|# deb [signed-by=/usr/share/keyrings/openmediavault-archive-keyring.gpg] http://packages.openmediavault.org/public/ sandworm main|' /etc/apt/sources.list.d/openmediavault.list

# For the synchrony repo (added automatically by omv-release-upgrade):
sudo sed -i 's|^deb \[signed-by=/usr/share/keyrings/openmediavault-archive-keyring.gpg\] http://packages.openmediavault.org/public synchrony main|# deb [signed-by=/usr/share/keyrings/openmediavault-archive-keyring.gpg] http://packages.openmediavault.org/public synchrony main|' /etc/apt/sources.list.d/openmediavault.list

⚠️ Note: omv-release-upgrade rewrites this file during the upgrade and re-adds the broken repo. You may need to comment it out twice — once before and once after the script runs. Always check with cat /etc/apt/sources.list.d/openmediavault.list before each attempt.

After commenting it out, verify and re-run:

cat /etc/apt/sources.list.d/openmediavault.list
sudo apt update && sudo omv-release-upgrade

❌ Web UI returns 502 Bad Gateway after upgrade:

The PHP-FPM socket for OMV (php8.4-fpm-openmediavault-webgui.sock) doesn’t get created automatically. Fix it by regenerating the PHP-FPM pool config via Salt:

sudo omv-salt deploy run phpfpm

Verify the socket was created:

ls -la /run/php/
# Should show: php8.4-fpm-openmediavault-webgui.sock

After that the web UI should load normally.

❌ “Sub-process dpkg returned error code 1” during upgrade:

sudo dpkg --configure -a
sudo apt-get install -f

Then re-run sudo omv-release-upgrade.

❌ Services not starting after upgrade:

sudo omv-salt deploy run --all

This re-applies the full OMV Salt state and usually brings everything back online.

❌ Docker containers are running but unreachable after upgrade:

After the upgrade, orphan Docker bridge interfaces with old subnets may remain, conflicting with the working container networks. Symptoms: docker ps shows containers as Up, but services are unreachable.

Check for duplicate routes:

ip route | grep "172\."

If you see two lines with the same subnet (e.g. two 172.19.0.0/16) — there’s a conflict. Compare the interface IDs with Docker’s network list:

sudo docker network ls

Interfaces not present in the Docker network list are orphans. There may be many of them. Delete each one:

# Replace br-XXXXXXXXX with actual orphan interface names
sudo ip link delete br-XXXXXXXXX

Verify no duplicates remain:

ip route | grep "172\." | awk '{print $1}' | sort | uniq -d
# Should return nothing

⚠️ Orphan interfaces will not come back after reboot — they are not attached to any Docker network. If many services are unreachable, check all routes and remove all orphan interfaces before investigating further.

Some plugins need version-specific updates. Check System → Plugins — if an installed plugin shows a warning or is missing, uninstall it and reinstall the OMV 8-compatible version.f an installed plugin shows a warning or is missing, uninstall it and reinstall the OMV 8-compatible version.

Wrapping Up 🎉

The short version: you can always update OpenMediaVault without losing data because OMV’s update system only touches the OS layer — your data drives are completely separate. Minor updates are a one-liner (sudo apt update && sudo apt upgrade -y) or a few clicks in the web UI. Major version upgrades take a bit more prep — back up the config, open tmux, run sudo omv-release-upgrade, reboot — but they’re well-tested and generally go smoothly.

The backup-first habit is the only thing standing between you and a successful upgrade. If you follow this guide every time you update OpenMediaVault without losing data, upgrades become routine maintenance instead of a gamble.

🐳 Running WordPress + MariaDB in Docker on OpenMediaVault — if you run Docker workloads on your NAS, check this guide for setup pitfalls to watch out for during upgrades
🌐 Running Nextcloud in Docker on OpenMediaVault with RAID storage — keeping user data on a separate RAID array is the safest architecture for any NAS upgrade
💤 How to Completely Disable Disk Sleep/Spindown on OMV — a useful post-upgrade check if your drives behave differently after kernel updates
🐳 Docker Hardened Images for Self-Hosting — running hardened containers is a great next step after you’ve stabilized your updated NAS

External references: