JorgeB

If the syslog server is running, post that log, if it's not, enable it and post it after the next crash.

Looks good for now; replacing the cables is a good idea to rule that out, if you notice any issues with Docker, recreate the Docker image.

Looks like you forgot both.

If the pool is now fixed but the GUI is out of sync, you can just reimport it (make sure you unmount it first if it was mounted manually) on main click on the first device for that pool and then "remove pool" back on main, create a new pool with the same name and 2 slots assign the pool devices, leave the filesystem set to auto start the array to import the pool

That suggests a corrupt share cfg file, diags my show the issue.

The pool is currently only using one device; the other is missing. First reimport the pool using only the good device (sdc) on main click on the first device for that pool and then "remove pool" back on main, create a new pool with the same name and 1 slots assign the good pool device, leave the filesystem set to auto start the array to import the pool The pool should be imported degraded, since it's using single profile, you will need to use th CLI to correct it, with the array running type: btrfs dev remove missing /mnt/cache Now reimport the pool once more with the single device, it should now be imported without being degraded. If yes, you can now add one device and then the other one.

Lot's of spam on the syslog, difficult to see anything else, reboot in safe mode, and if the docker still crashes post new diags

No ATA errors during the rebuild, which is good news. It's possible, and I don't remember if I asked before, but if there are any power splitters in use it could also be the problem

Should work; can't comment on the iGPU stuff since I never used it.

Cache device dropped offline; check/repace its cables and post new diags after array start.

Not as far as I know.

It will check the whole pool. With different-sized devices btrfs can now use raid0, but not sure that was supported with the kernel in 7.2, so best to use single, with the array running type btrfs balance start -dconvert=single,soft -mconvert=raid1,soft /mnt/home Any there are any issues during the balance and it aborts, post new diags.

First run the server in safe mode without any plugins to confirm the issue doesn't happen. If it doesn't, then start enabling them, you can start with half, if it still doesn't happen, try the other half, then keep drilling down.

Just to be clear, what ran out of RAM before was just that container, not the server.

-Tools -> New Config -> Preserve current assignments: All -> Apply Then unassign one of the parity drives, if that's what you want; should leave parity1 in use. Start the array to begin parity sync, and you can then also format disk7 at any time.

You can use this board to report any CA template issues: https://product.unraid.net/b/community-apps-submission-support

Hopefully it's resolved, but if it happens again, post new diags.

That is correct; this is for updating packages for 7.2, which were already updated for 7.3.2

It's normal for the balance to fail with not enough space, but that should not corrupt data, possibly an unrelated issue. See if you can mount the pool with skip_balance, and if yes, scrub it and post the results. With the array stopped type mkdir /x mount -t btrfs -o skip_balance /dev/sdg1 /x the type btrfs balance cancel /x umount /x Then restart the array and post new diags.

There is a CPU power profile setting - Settings - Power, but that won't really help if there's a PSU issue.

Key being wrong suggests some LUKS header corruption, assuming for sure it's the same one. I'm also seeing a zfs pool detecting data corruption: Jul 24 23:01:46 Tower emhttpd: errors: 4 data errors, use '-v' for a list That may or may not be related; data corruption is typically a RAM issue, but you appear to be using EEC RAM, but whatever caused that could also have corrupted the LUKS header. You can try manually decrypting the rebuilt disk just to confirm the key, but I would expect the same result, this would need to be done with the arry stopped. cryptsetup luksOpen /dev/sdX sdX For the future, make sure you have LUKS backups, and I only recommend using encryption if absolutely necessary; if not, it just adds one more layer that can go wrong when a problem occurs.

Create the new flash with the USB tool using the current version, then restore only the config folder from the backup. Also good to read the release notes for all the minor releases in between, (6.6.0, 6.7.0, 6.8.0, etc) especially if it's not just a simple NAS server.

I don't see how ATA errors can be caused by the flash drive. I recommend using the server for some more time to confirm it's really resolved; it would also be good to look at the diags after a few days of uptime.

Like mentioned, the HBA is PCIe 2 and it's linking corrclty LnkSta: Speed 5GT/s, Width x8 You also have NVMe liking at 8GT/s, so the board is correctly supporting PCIe 3.0, the Nvidia may be in a slot that is set to PCIe 1.0, or there is some other issue with it.

My first recommendation would be to see if it still happens in safe mode.