JorgeB

So why are you mentioning signing the flash drive? If the SSD is not booting, you can boot once more from a flash drive and manually import the setting from the zfs boot pool, assuming it's still working. This requires using the CLI, but I can post the steps if needed, I'm just not sure if I understand the current problem correctly.

I thought you were booting from an internal boot pool?

That error usually means Secure Boot is enabled in the BIOS. The BIOS update may have enabled it again. Enter the BIOS/UEFI settings and disable Secure Boot, save the changes, then reboot. Keep TPM enabled. Also make sure your internal Unraid boot device is first in the boot order.

The array is fine: the rebuild completed without errors and all disks look healthy, so recreating the docker image was the correct fix. Most likely cause: your docker.img was on the array (the system share isn't set to use a pool), and the video you followed moves data off the disk before replacing it. If docker.img got moved while the Docker service was running, the copy ends up inconsistent, and that matches the error you were getting. The rebuild itself would not cause this. To avoid this in the future, and for better performance, I would move the docker image and appdata to the cache pool. Note that the new docker.img was again created on the array, and appdata is set to cache only but it also has files on disk1 and disk2: - Settings > Docker and Settings > VM Manager: disable both services - Shares: set system and appdata to primary storage cache, secondary storage array, mover action array -> cache - Run the mover from the Main page and wait for it to finish - Click "Compute" for those shares to confirm everything is now on cache, then set secondary storage to none - Re-enable the Docker and VM services Since you are reinstalling the containers, you can do this first, then recreate the docker image so it's created on the pool. Use Apps > Previous Apps to reinstall them with the same settings. Also, always stop the Docker and VM services before moving those shares, with the mover or any other tool. And as already mentioned, you don't need to move data off a disk before replacing it, Unraid rebuilds the contents to the new disk. Unrelated: the syslog is being spammed with ata9 reset errors. That port has no detected device. If something is connected to it, check or replace the SATA cable, or disconnect the cable if nothing is supposed to be there.

These diagnostics look good. The connection problem looks fixed. There are no disk link errors since the reboot. That covers more than a day, including the whole parity check so far, which is the heaviest load the disks get. All disks show 0 errors. About the speed: the check is past 90%, and it was still running at about 130 MB/s. Hard drives are slower near the end of the disk, so going from about 200 MB/s to 150 MB/s or lower at this stage is normal. About the "P corrected" lines: these are expected. Parity was out of date in places because of the unclean shutdown and the earlier connection drops. This correcting check is fixing that. These corrections only update the parity disk. They don't change anything on your data disks. Unraid logs only the first 100 lines and then stops logging. The total so far is about 8000. What I recommend: 1. Let the check finish. 2. Then run one more parity check, with "Write corrections to parity" unchecked. It should finish with 0 errors. If it does, the array is back in sync. If it finds errors again, post diagnostics after it completes. About the disk5 SMART warning: the reallocated sector count went from 1 to 2. That means the disk replaced one more bad sector with a spare. One or two is not a reason to worry. Just keep an eye on it. If the number keeps going up, that disk should be replaced. After the parity checks you can also run an extended SMART test on disk5. About the missing data: I don't see any sign of data loss in the diagnostics. Disk usage is the same as yesterday, and there are no filesystem errors. Can you give me some examples of what is missing (the share and folder or file names), and when you last saw them? If you use apps like Sonarr or Radarr, also check whether they renamed or moved those files. The log shows one TV episode that was no longer found under its old name. After the second check comes back clean, you can go ahead with the cache pool.

Shoudl be fine

This is normal with pr-plugins, they are meant to be used temporarily, and so that you don't forget it is installed.

To expand a little more, basically, if the disk is disabled (red x), user always needs the unassign/reassign flow. If it's invalid (orange triangle), which IIRC was not the case, it would rebuild at array start directly; but the unassign/reassign always works for rebuilding.

You have to use USB or TPM, please post the diagnostics.

At 09:33:12, about 3 minutes into the update and while it was writing the new files, your USB stick disconnected from the server. It reconnected a second later, but it was not mounted again. Since then the server has been running without its boot drive. That is why you see the setup wizard, the boot drive warning and the I/O errors, why diagnostics never finish, and why the API, GUI and SMB stopped one after another. Plex keeps working because it was already running in memory. Your stick is also very small for current releases. It's 4 GB, but the Unraid partition on it is only about 2 GB, which explains the roughly 200 MB free. The disconnect itself points to the stick failing under the update writes. Either way, it's time to replace it. Your array and pool data is not affected by any of this. To your questions: Fix remotely: Unfortunately not reliably. The writes that were in progress when it dropped were lost, so the files on the stick, including the boot files, are probably incomplete or damaged. Leave it running: It's fine to leave it running for Plex until someone can work on it, but expect more things to stop working, and nothing you change now will be saved. Diagnostics won't complete in this state, and the syslog you posted already shows the cause, so don't worry about them. Power cycle: Please don't just reboot it on the old stick hoping it comes back. It will most likely fail to boot, or boot without a valid configuration. When you're ready to shut down, your son can log in at the local console as root and type powerdown, or press the power button briefly once. If it hasn't turned off after several minutes, holding the power button is OK. The worst case is a parity check on the next start. Backing up the old stick: Yes, that's the right first step. After shutting down, plug the old stick into a Windows PC. If Windows offers to scan and fix it, say no for now. Copy the whole stick to the PC, especially the config folder. Tell us if any file inside config fails to copy. Getting back up: 1. Use the Unraid USB Creator to write the new stick. Ideally 7.4.0 or 7.3.4 is fine, use that and update later from Tools > Update OS. 2. Copy the config folder from your backup onto the new stick, replacing the one there. 3. Boot from the new stick. Because the license is tied to the old stick, go to Tools > Registration and use Replace Key to move it to the new one. Your son can do this with the steps above, or you can wait until you're home. Scheduled backup: If any config files on the old stick turn out to be unreadable, the scheduled flash backup is the fallback, so please find out where it was saved. If you can still reach the server over SSH through Tailscale, it's worth copying the newest backup file to another computer now, while the server is still up.

Install only the correct license. Also note that the license is never tied to the internal boot device/pool, it's either tied to a flash drive or TPM. When using a flash drive for licensing only, it should be formatted FAT32 and must be labeled Unraid. It doesn't need any file there.

Unassigning disk1, starting array, stopping array, and reassinging it will always reset the assignment and rebuild. That's why I recommended doing that for both.

Go to Settings - Management Access - Unraid API Settings.

It's always best to post the full diags, but based on that, the docker image is corrupt, delete and recreate it: https://docs.unraid.net/unraid-os/troubleshooting/common-issues/docker-troubleshooting/#re-creating-the-docker-image-file Then: https://docs.unraid.net/unraid-os/troubleshooting/common-issues/docker-troubleshooting/#reinstalling-docker-applications Also see below if you have any custom docker networks: https://docs.unraid.net/unraid-os/troubleshooting/common-issues/docker-troubleshooting/#restoring-docker-custom-networks

Your diagnostics show Unraid 7.3.4, not 7.2.x. That is fine, just so it's clear. With two disks disabled on dual parity, you have no redundancy left. The emulated disk1 and disk4 depend on every other disk, including disk10, reading correctly. Some good news about disk10. All of its logged read errors are at the same location. The 16 pending sectors are only two 4K physical sectors. The last error was about 1,000 power-on hours ago, and the current syslog has no read errors for it. So the damage looks small. With some luck, at worst, the rebuilt disks will have a few KB of wrong data at that one offset, if that area is in use. Disk1 and disk4 both have a lot of UDMA CRC errors. Both are on the second LSI HBA, on the same cable as disk2 and disk3, which have none. CRC errors are a connection problem, not a disk problem, and the most likely reason both were disabled. The syslog also shows an onboard SATA link failing at boot, which is probably why disk1 was missing earlier. To answer your questions: 1. Yes, rebuilding onto the same disks is fine. Their contents are from 2024, so they are not useful as a backup, and the different UUID on disk1 confirms this. I would rebuild disk1 and disk4 at the same time. Dual parity can do that, disk10 only has to be read once, and both parity levels are back when it finishes. 2. Suggested sequence: - Keep Docker, VMs and the mover disabled. Make sure anything irreplaceable on disk1 and disk4 is backed up, because right now the emulated disks are the only copy. - Power down and replace the cable that goes to disks 1 to 4 on the second HBA. Also check the power connections to disk1 and disk4. - Run an extended SMART test on disk4. Its last test was a short one at about 38,000 hours, it now has over 73,000, and it has 10 reported uncorrectable errors. If the test fails, rebuild disk4 onto a new disk instead (up to 18TB). - Rebuild both disks: stop the array, unassign disk1 and disk4, start the array, stop it, assign both disks again, then start the array. Optional: start in maintenance mode. This way nothing writes to the array during the rebuild. - When it finishes post new diagnostics. I want to check whether disk10 had read errors during the rebuild. 3. There is no real value in keeping the old disks untouched. Their data is outdated. If you have spare disks and prefer to rebuild onto those, that works too. 4. For disk10, wait for the new diagnostics. Then replace it with a CMR disk no larger than your 18TB parity disks: stop the array, assign the new disk to disk10, and start the array to rebuild. You will have full redundancy again during that rebuild. Once everything is fixed, set up notifications, so a disabled disk does not go unnoticed for that long again.