Upgrading unRAID 7.0.1 to 7.3.2 in One Jump: 13 Risks, 3 Minutes Down
How I planned a three-minor-version unRAID jump with 13 written risks and an answer for each, what the 3-minute upgrade looked like, and the fallout that showed up after.
HomeLab, unRAID and storage. Updated . 7 min read.
I skipped two minor versions of unRAID in a single reboot, from 7.0.1 to 7.3.2, and the box was down for three minutes. The reboot was the easy bit. The plan behind it listed 13 things that could break on this specific box, and wrote an answer next to each one before anything was clicked.
What I didn't see coming was the fallout from containers I'd created by hand during an earlier outage.
TL;DR: update plugins first, swap out the ones whose repos are archived, and take a fresh off-box flash zip you've actually tested. On the day, change nothing that blocks a rollback: no ZFS pool upgrade, no internal boot, no TPM. Then run a read-only after-check list. The upgrade went clean. The work was in containers that unRAID 7.2+ no longer treats as its own.
Why one jump
The box is an Intel NUC with 2 data disks plus parity, a ZFS cache SSD, 48 containers, and two VMs. It was on 7.0.1 with kernel 6.6.78.
The reasons to move were mostly security and the kernel. 7.3.2 fixes a webGUI update.php path traversal (CVE-2026-3838), 7.3.0 patches two kernel privilege escalations, and dozens of base packages get CVE fixes. The kernel goes from 6.6.78 to 6.18.38, ZFS from 2.2.7 to 2.4, Docker from 27 to 29. The box came up on ZFS 2.4.3 and Docker 29.5.3.
One line in the 7.3.2 kernel config mattered more to me than the rest: CONFIG_USB_AUTOSUSPEND_DELAY=-1. USB autosuspend is off. My boot flash had fallen off the USB bus twice in nine days just before this, so one less way for a USB device to drop was worth having.
Stepping through 7.1 and 7.2 would have meant more reboots and more rounds of checks. The rollback path is the same either way: Tools > Downgrade OS puts back the previous release from /boot/previous.
Reading the box before reading the release notes
An AI agent wrote the plan over SSH, and every fact about the box was read live that morning. That's the part most upgrade checklists skip. They list the release's known issues, not the ones that meet your config. A few examples of what it pulled:
br0is ipvlan, IPv4 only, and the only container on it is AdGuard Home, the house DNS./boot/extracarries abluezpackage for Home Assistant's Bluetooth.- The syslinux append line has
pcie_aspm=off, which the SATA card needs. - sshd runs from a custom config under
/boot/config/ssh. - The ZFS cache pool's features were never upgraded.
- TPM wasn't visible:
/dev/tpm*absent, Intel PTT off in the BIOS.
Then Codex red-teamed the plan. It agreed with one jump and added four things: stop VMs, Docker, and the array by hand before the reboot; a DNS preflight against the backup resolver; a console-level rollback; and service checks by IP rather than by process. It also caught a wrong claim in the plan, that the M.2 slot was free. It isn't. It holds the SATA adapter for the array.
The 13 risks
| # | Risk | Answer |
|---|---|---|
| 1 | AdGuard on br0 loses its network | Three known br0 bugs, none matching this box exactly. The array-start script already reconnects it. If Docker says network br0 not found: disable and re-enable Docker, run the script by hand. The hub's AdGuard over WireGuard keeps the house resolving meanwhile |
| 2 | Plugins | Update all before the OS. Replace compose.manager (repo archived) with Compose Manager Plus, and folder.view (author gone) with FolderView3 |
| 3 | bluez from /boot/extra built on the old base | If bluetoothd fails, un-get update && un-get install bluez, rerun the script |
| 4 | Docker 27 to 29 drops old API versions | Only Glances and Homepage use the socket, both current. No template uses --mac-address |
| 5 | http://localhost needs a login since 7.2 | No script calls the webGUI on localhost. Checked |
| 6 | Samba 4.23 | Run the Windows PC backup once after; that share already had an ERROR 50 history |
| 7 | VMs | QEMU 10.2 keeps the 9.1 machine types. Both VMs are other people's servers, so announce a window |
| 8 | ZFS 2.4 on a 2.2 pool | Reads it as is. Do NOT press "upgrade pool": it blocks the rollback |
| 9 | sshd | OpenSSH 10.2 knows every directive in use (PerSourcePenaltyExemptList exists since 9.8). Console if ssh fails |
| 10 | Kernel command line | The updater writes syslinux.cfg-, not syslinux.cfg, so pcie_aspm=off survives. Verify in /proc/cmdline |
| 11 | Kernel 6.18 USB drivers | cp210x (Zigbee dongle) and btusb are in-tree; the by-id path doesn't change |
| 12 | License | Stays flash-based. No internal boot or TPM on the day: both block a rollback below 7.3.0 |
| 13 | Rollback | Tools > Downgrade OS. Without SSH or UI: keyboard and monitor on the NUC, or pull the stick and copy the old bz* files and their .sha256 from the tested zip |
Rows 8 and 12 are the ones I'd tell anyone to copy. The rollback is only real if nothing on upgrade day moves a one-way switch.
Row 13 is backed by a zip, not a hope. The off-box flash copy taken that day was tested with unzip -t and holds the 7.0.1 bzimage, bzroot, bzmodules, and bzfirmware. If the new kernel won't boot, those four files go back over the stick's root from the PC, and the box boots the old release.
What actually happened
The plan said the next evening, with a 45-minute window. I ran it the same morning at 10:05 instead.
Plugins updated, Compose Manager Plus and FolderView3 installed, Install Update from the account app, then a plain Reboot. I skipped the manual stops the plan asked for. Down 10:09 to 10:12. The array started clean, with no parity check.
The after-check is all read-only, run from ssh nuc:
cat /etc/unraid-version; uname -r; cat /proc/cmdline # 7.3.2, 6.18.38, pcie_aspm=off present
grep -E '^(mdState|rdevStatus\.[0-2])' /var/local/emhttp/var.ini # STARTED, DISK_OK x3
zpool status cache | head -12 # ONLINE, "features not enabled" is expected
docker network inspect br0 --format '{{.Driver}} {{json .IPAM.Config}}'; ip link show shim-br0
docker ps --format '{{.Names}}' | sort | diff /boot/config/pre-upgrade-containers.txt -
virsh list --all # both running
pgrep -a bluetoothd; hciconfig | head -2 # bluetoothd up, hci0 UP RUNNING
ls -l /dev/serial/by-id/ # Zigbee dongle presentAll green. pcie_aspm=off survived. The ZFS pool came up ONLINE. br0 was intact, and unRAID created shim-br0 on its own, which my array-start script used to do. DNS answered, both VMs came up, bluetoothd and hci0 came up without reinstalling bluez, the Zigbee dongle was there, Tailscale was online, and the sshd config was kept. None of the 13 risks fired. The closest call was a side effect of the fix for risk 2.
The fallout
The problems came from things the plan couldn't read from a config file.
Four "3rd party" containers. During the August outages I'd recreated a few containers from the shell with docker run. They had no net.unraid.docker.managed=dockerman label, so the 7.2+ Docker page showed them as 3rd party and wouldn't edit or update them. Two had templates. Two didn't, so I wrote new ones. All four were recreated from templates with the label. One of them, the Eufy bridge, only survived reboots before through --restart=unless-stopped. It's on the unRAID autostart list now, right before the MQTT broker.
Compose Manager Plus and the project name. Plus takes the project name from the stack's name file. The old plugin had created one stack's containers under hoarder_app, so on first autostart Plus tried to build new containers and hit a name conflict. The fix was one line: the name file now says hoarder_app.
A retired stack. A compose stack I'd stopped using still had autostart on and failed every boot. It's off now.
The Telegram bot. It times out before the network is up on every boot and needs a manual docker start. That was true before the upgrade too; it just showed up again in the after-check.
A SMART flag that isn't there. The new dashboard flags the unassigned spare disk with a SMART error, while smartctl -H says PASSED with 0 reallocated or pending sectors. Still open: I haven't found which attribute the 7.3 UI reads.
What's next
7.3 can boot the OS from an internal SSD and keep the USB stick only as the license key. That kills the flash-drop failure class for good. It wasn't in scope for the day, because it blocks a rollback below 7.3.0, and because this NUC has no free internal slot: the M.2 holds the SATA adapter and the 2.5" bay holds the cache SSD. A small SATA SSD on one of the adapter's two unused ports is the candidate. That's its own job, now that the upgrade has settled.
Questions
- Can I upgrade unRAID from 7.0 straight to 7.3?
- Yes. I went from 7.0.1 to 7.3.2 in one jump through Tools > Update OS. Update every plugin first, replace plugins whose repos are archived, and keep a fresh off-box flash backup. Downtime was about three minutes.
- What blocks a rollback after an unRAID 7.3 upgrade?
- Upgrading the ZFS pool features in the UI, enabling internal boot, and enabling TPM licensing. Each one blocks going back to the older release. Leave all three alone on upgrade day and Tools > Downgrade OS stays available.
- Why does unRAID 7.2 or 7.3 show my container as 3rd party?
- The container was created outside the Docker page, for example with docker run from the shell, so it has no net.unraid.docker.managed=dockerman label. unRAID then cannot edit or update it. Recreate it from its template to add the label.
- Why did Compose Manager Plus try to recreate my stack?
- Compose Manager Plus takes the project name from the stack's name file. If the old plugin created the containers under a different project name, autostart builds new containers and hits a name conflict. Set the name file to the old project name.