JorgeB

The partition-start issue from the other thread is not the cause here, and you should not run that sgdisk command, since on disk1 it would move the partition start away from where the filesystem actually is. Disk1's partition starting on sector 2048 is a valid layout that spans the whole disk, and Unraid uses it as is in both releases. The problem is that 7.3.3 identifies your USB disks differently due to a kernel package update, that's one of the reasons we don't recommend using USB for array or pools. It now uses the model and serial of the disk inside the enclosure instead of the USB enclosure ID, for example WD_Elements_2621_...-0:0 became WDC_WD50NDZW-11BCSS0_WD-.... It's the same disks, but since the IDs don't match the saved assignments, all three are shown as wrong. Your cache SSD is not affected, its ID is the same in both releases. To fix it, upgrade to 7.3.3 again, then: 1. Go to Tools > New Config, set "Preserve current assignments" to "Pool slots", and apply. 2. On the Main page assign: - Parity: WDC_WD60NDZW-11C8XS0 - Disk1: WDC_WD50NDZW-11BCSS0 - Disk2: WDC_WD50NDZW-11BCSS1 3. Check "Parity is already valid" and start the array. All disks should mount normally. 4. Since the assignments were changed a few times, run a non-correcting parity check afterwards. It should find 0 errors. Note that if you ever go back to 7.3.2, the IDs will change back and you would need to do another New Config. Unrelated, but disk2 has 3 pending sectors, keep an eye on that.

You do if the license is tied to it, the license can only be tied to a flash drive or TPM 2.0 device, not to an internal boot pool.

Please post the diagnostics.

Thanks, but this has already been reported here: https://product.unraid.net/b/cve-reports/p/cve-2026-109618-cve-2026-109619-severe-php-vulns That's the current board to report/follow any security issues

Glad to hear, and thanks!

The screenshot shows the flash drive disconnecting during boot. Unraid finds it and starts checking it, but then the flash stops responding on USB and drops off. After that it can't be read, so /boot can't be mounted and boot stops. Together with the BIOS sometimes not detecting it, this points to a failing flash drive, or less likely the USB port. First, shut down and plug the flash into a different USB port, ideally a rear USB 2.0 port directly on the board, with no hub or extension cable, and try booting again. If you don't have a recent flash backup, before anything else put the flash in another computer and copy the whole contents to a safe place, especially the config folder. You can also run a check on it there. If it drops off again on a different port, or the other computer also has trouble reading it, replace the flash. Create a new one with the USB Creator, copy your config folder back to it, then boot and transfer the license to the new flash when prompted.

Image is not visible, please try again.

Docker appears to be working normally to me. Each container starts in about a second, but several of them have an autostart wait set: - 120 seconds: Czkawka, OpenSpeedTest, DiskSpeed, qdirstat and ollama - 60 seconds: karakeep, pgadmin4, RedisInsight, heimdall and Norish - 30 seconds: tautulli When a container has a wait, Unraid waits that many seconds before starting the next container in the list. Those waits add up to about 15.5 minutes, and that is almost all of the time it takes. Autostart has always started containers one at a time in the order shown. The waits are meant for containers that others depend on, for example a database that must be up before the app that uses it. With no waits, 40 containers start in under a minute. My guess is that these waits were added since your last reboot 5 months ago, so this was the first boot where they were used. To fix it, go to the Docker page and switch to Advanced View. In the autostart column, clear the wait value (or set it to 0) for every container that nothing else needs to wait for. If an app does need its database or Redis first, put the database above the app in the autostart order and give it a short wait, like 10 to 15 seconds. That should bring startup back to a minute or two.

Please post the diagnostics.

I tried that already but could not repro, started with a 4-drive raidz1, expanded the pool with a 5th drive, stopped the array before the expansion was complete, tried to add 2 other devices. The array doesn't start with an "invalid expansion" error, so please let me know if you can repro, and the steps to do it.

See if the MCEs stop after this; if they continue to occur, there's likely still some hardware issue.

Yes, those /root sizes look normal now. The new diagnostics also show rootfs at only 6% used, so the earlier RAM-backed filesystem problem appears resolved, I'm not familiar with Plex, but it may be doing some maintenance task at that time; you can try giving it a little more RAM.

These show repeated corrected internal-parity errors in bank 0, mostly on logical CPU 7, with one on CPU 3. “CPU 7” is a logical processor number, so it does not necessarily mean physical core 7. Checking for dust and improving airflow are reasonable steps, but these records do not establish overheating. Please record CPU temperatures and any thermal throttling during normal use, then see whether new machine-check errors appear after improving cooling. There are also entries throughout late September and early October, so the hardware errors continued during the period when the server otherwise appeared stable. If the errors continue at normal temperatures and stock settings, I would seek hardware-vendor diagnosis. These corrected events do not prove that the CPU is defective or that they caused the Btrfs corruption, but they deserve investigation.

looks like you forgot

The logs show corruption before the later parent transid errors. September’s log includes metadata corruption detected while preparing a write, and October’s invalid-address errors started on October 17, before the pool went read-only. Both cache SSDs currently report zero media errors and zero error-log entries. That does not exclude a storage fault, but there is no clear evidence that one failed SSD is bringing down the mirror. Switching to a single SSD would reduce redundancy without addressing the cause. The machine-check notifications deserve investigation alongside the write-time corruption. RAM, the CPU or its memory controller could be involved, although these logs do not identify a failed component. The earlier clean Memtest86+ result does not rule out an intermittent fault. Keep Docker and the VMs stopped while you secure a current, verified backup on separate storage. Do you have any decoded machine-check records from your monitoring tools? The diagnostics contain the notifications, but not the details needed to identify the affected subsystem. Also confirm whether XMP, CPU overclocking or undervolting is enabled. Further memory testing should use stock settings, testing each DIMM separately. Put the syslog receiver on a system that does not depend on this cache. A writable mount after reboot and a clean scrub do not establish that the original problem was fixed. I would avoid btrfs check --repair or reformatting at this stage.

The diagnostics confirm that the BIOS update is installed, but unfortunately the freeze has recurred. The previous log ends without a recorded crash error, and the next boot records use of the reset pin. Try disabling Global C-state Control next. Confirm that Power Supply Idle Control remains set to Typical Current Idle, with CPU and RAM at stock settings. Also run Memtest for several complete passes. Any errors need investigation, although a clean result cannot completely rule out memory instability. The repeated rc. text alone is not enough to identify the problem. If it happens again, photograph the whole screen and attach fresh diagnostics after rebooting. Keep syslog mirroring enabled.

If I understood correctly, I cannot reproduce this the way you describe, started with a 4-device raidz1 pool, expanded it to 5 devices, then tried to add 2 more, and it's not allowed as expected. If you remember, please post step by step what you did to arrive at that result, there may be a bug, but only under some specific circumstances.

The endpoint error and recovery after restarting Docker suggest that Docker retained an existing network attachment for a stopped container. These diagnostics do not establish what caused that state. The memory warning shows a rejected allocation of approximately 42 TiB. There is no OOM-killer event in the supplied logs. A container network interface becomes disabled four seconds later, so the timing could be relevant, but we cannot identify the container. Which two containers were affected, and when did they stop? Are they managed through Unraid’s Docker templates or Compose Manager Plus? Did this follow a container update or backup? If it happens again, please collect diagnostics before restarting Docker or disconnecting networks. Also run this for each affected container, replacing CONTAINER with its name: docker inspect --type container --format 'State={{json .State}} Networks={{json .NetworkSettings.Networks}}' CONTAINER This will capture its exit state and network attachments while the problem is present.

You don't need to mark it as fail, just use the 12TB to replace it.

So the last two were added at the same time?

Your docker.img looks fine. It mounts normally, it is not a new image, and Docker starts without errors. FolderView3 is also not the problem. When Docker starts, Unraid goes through every container that Docker knows about to restore its networks. In your diagnostics that list only has your autostart containers, plus blender and the Nextcloud AIO containers. So the other containers were removed from Docker itself. They are not just hidden on the Docker page. This had already happened before this morning's first boot. Your apps and settings shoudl not be lost. If the templates are still on the flash drive and your appdata is untouched you can get the containers back with Apps > Previous Apps: select the missing ones and install them. They will use the same settings and appdata. To find what removed them, note that only stopped containers seem to be affected. That points to something that runs a "docker container prune" or "docker system prune", because that command deletes all stopped containers. Please check: - Any User Scripts, especially scheduled ones, that run a docker prune or cleanup command. - Whether you ran a prune command manually, or used a cleanup option in a plugin, before shutting down yesterday. - Whether blender was running at that time. It is the only container without autostart that survived. Your syslog server saves the log to a share. Please post that log file for the time before yesterday's shutdown. It should show what happened.

There appears to be a container constantly restarting; check their uptimes.

Please post the diagnostics.

I would recommend posting it here: https://product.unraid.net/b/cve-reports

The new XFS disk1 and the parity sync both look good in the diagnostics. The problem is the 12TB itself. Because of everything that happened to it, it still has a leftover XFS signature at the start, as well as the ReiserFS one we repaired. With two signatures, UD can't tell what the disk is, so it says there's no file system and greys out Mount. The rsync failed because that mount folder didn't exist. We won't try to "fix" the leftover signature, because we don't want to write anything to that disk. Instead, we mount it by hand, read-only, like we did before. 1. Check the device letter since it can change, it should still be sdn, if not adjust. 2. Mount it read-only: mkdir -p /mnt/recover mount -t reiserfs -o ro /dev/sdn1 /mnt/recover ls /mnt/recover You should see your share folders and lost+found, like last time. 3. Start tmux, then copy: rsync -a --info=progress2 --exclude=lost+found /mnt/recover/ /mnt/user/ The progress still shows on screen. 4. When it's done, unmount: umount /mnt/recover Before you start, the same checks as before apply: no share should use a cache pool as primary storage, and Minimum free space should be set. Most of the data will go to disk1, since that's where the free space is. Again, don't format or reuse the 12TB until you've checked your shares. Also, for later: Fix Common Problems shows that your cache SSD is ReiserFS too. Besides the 8TB disk, that also has to be converted before you can update to 7.3. We can do that after the copy is finished.