Unraid 7.3 upgrade and recovery threads need a preflight for webUI lockups, missing drives, and power-loss corruption
Upgrading Unraid to 7.3.x has a pattern of post-reboot surprises: a frozen webUI, an array where every drive shows missing, or a USB boot drive corrupted by forced power cycles. Running a short preflight checklist before you touch the upgrade button is the difference between a smooth evening and a multi-day recovery.

Upgrading Unraid to 7.3.x has a pattern of post-reboot surprises: a frozen webUI, an array where every drive shows missing, or a USB boot drive corrupted by forced power cycles. Running a short preflight checklist before you touch the upgrade button is the difference between a smooth evening and a multi-day recovery.
What the forums are actually reporting
Three distinct failure modes have surfaced in fresh threads after the 7.3.x releases, and they are worth treating as a cluster rather than isolated edge cases.
webUI and Docker page lockups. One thread describes Unraid 7.3.1 locking up the webUI so completely that even the Docker page becomes unresponsive. The usual escape hatches — clicking "Stop Array," gracefully stopping containers — are unavailable because the UI itself will not respond. The only exit is a hard power cycle, which carries its own risks (see the USB corruption section below).
Every array HDD showing as missing after upgrade. A second thread walks through a jump from 7.0.0 to 7.3.1 where the array came back up with all hard drives flagged as missing. The drives were physically present and readable, but Unraid could not reconcile the array configuration from the older version. The only confirmed recovery path in that thread was downgrading back to 7.0.0 and restoring the previous flash backup.
Cascading Docker failures during a restore attempt. A third thread describes a total-failure scenario: Docker services stop, the operator follows restore steps from the documentation, but each step leaves the server in a worse state than before. The uncertainty centers on a media stack (likely Plex or Jellyfin plus *arr services) where container volumes and paths need to be reassembled in the right order.
None of these are theoretical risks. They are documented user experiences from the current release cycle.
The USB boot drive corruption loop
Unraid boots from a USB flash drive, and that design choice becomes a liability when the system cannot shut down gracefully. Forced reboots after a webUI lockup write incomplete data to the flash drive. Do that enough times and the drive itself becomes unbootable.
One thread asks a pointed question: how do you stop the cycle of USB corruption after repeated forced reboots? The answer involves two separate mitigations.
First, keep a current flash backup. Unraid's "Tools → Flash Backup" creates a ZIP of your USB contents. Download it before every upgrade and store it somewhere the NAS itself does not control — a separate machine, an external drive, or a cloud location. If the drive corrupts, you restore from the ZIP to a new USB key and you are back in business within minutes rather than hours.
Second, consider the write-protect or RAM-mode options that reduce how often Unraid writes to the flash during normal operation. Fewer writes during a crash mean less corruption exposure. Check the Unraid documentation for your specific version, as the options have moved between releases.
How to structure your preflight before upgrading
The patterns above point to a preflight routine that takes about 20 minutes and pays for itself the first time something goes wrong.
Verify your flash backup is current. Go to Tools → Flash Backup, download the ZIP, and confirm the timestamp. A backup from three months ago does not protect you from a configuration you added last week.
Record your array disk assignments. Open Main and write down (or screenshot) every slot: which disk serial is in parity, which is in disk 1, disk 2, and so on. The missing-drives thread shows that Unraid can lose this mapping across certain version jumps. Having the ground truth on paper means you can re-assign manually if needed.
Export your Docker template XML files. Your container configurations live in /boot/config/plugins/dockerMan/templates-user/. Copy that folder to a safe location. If Docker comes back empty after an upgrade, you can rebuild containers from these templates without re-entering every environment variable and volume path by hand.
Note your current Unraid version before you upgrade. If you need to downgrade — as the 7.0.0 to 7.3.1 thread required — you need to know exactly which version to roll back to. Unraid's previous versions are available from the "Previous Versions" tab on the flash backup restore page.
Check your UPS configuration. Forced reboots are the mechanism behind USB corruption. If your server is on a UPS, confirm it is correctly configured to initiate a graceful shutdown before battery runs out. If you do not have a UPS, that is a separate conversation, but at minimum make sure the server is not on a circuit that flips during normal household load.
A tool like ServerCompass can help you see all your running services at a glance before you start — it is worth confirming which containers are active so you know what needs to come back up cleanly on the other side of the upgrade.
If you are already in recovery mode
If you are reading this after the upgrade went sideways, the sequence that has worked for others is:
- Do not keep trying new restore steps if each one leaves the system worse. Stop, document the current state, and decide on a rollback first.
- Downgrade to your last known-good version using a flash backup from that era. This is why the version-specific backup matters.
- Bring the array back up and verify parity before touching Docker. Parity is your data integrity guarantee; restore it before worrying about containers.
- Re-add Docker containers one at a time using your saved template XMLs, starting with the most critical service. Confirm each one is healthy before adding the next.
Cascading failures in recovery happen when operators try to fix everything simultaneously. The media stack thread is a clear example: stopping all services, attempting a restore, and re-adding containers in the wrong order produces a state that is harder to diagnose than the original failure.
Checklist
- Download a fresh flash backup ZIP from Tools → Flash Backup before starting any upgrade
- Screenshot or write down every array disk slot assignment (serial numbers included)
- Copy your Docker template XMLs from
/boot/config/plugins/dockerMan/templates-user/to a location outside the NAS - Note the exact current Unraid version so you have a target if a downgrade is needed
- Confirm your UPS is configured for graceful shutdown before upgrading
- Use ServerCompass or a similar dashboard to record which services are running pre-upgrade
- If a webUI lockup forces a hard power cycle, check USB drive health before the next boot
- In recovery, restore array and verify parity before attempting to bring Docker containers back


