JorgeB

One thing you can try it to boot the server in safe mode with all docker/VMs disable, let it run as a basic NAS for a few days, if it still crashes it's likely a hardware problem, if it doesn't start turning on the other services one by one.

Nothing obvious, but diags show writing to 2 array disks at the same time, avoid that, also have you tried without encryption? There are a few isolated reports of bad performance when using it, another thing you can try is unpacking to cache using the disk share (/mnt/cache/share) instead of the user share.

Google TiB vs TB

Now do a new config, keep all assignments as they were and re-sync parity.

Look for the system event log in the BIOS, it might have more info, though don't know what kind of board is a Google Inc - 0JP31P

Not much, except avoiding large I/O operations, like parity checks or disks rebuilds, since it appears to be when this issue shows up the most.

You can wait for a newer one, a newer kernel on next Unraid release might also help, not much else you can do.

Shuched means drives removed from USB enclosures, some of these don't work if power by a SATA connector with 3.3v, but in any case until they show up in the BIOS they will never be detected by Unraid.

Anything can go bad at any time, if the diags don't point to the culprit basically you'd need to start swapping components around to find it.

Do they show up in the board BIOS?

Very unlikely, but you can just re-assign the disks, just amke sure all assignments are correct and check "parity is already valid" before array start.

By having dual NVMe devices installed you lose the first SATA port, all the other ones have nothing connected: Dec 7 05:23:36 TheVault kernel: ata5: SATA link down (SStatus 4 SControl 300) Dec 7 05:23:36 TheVault kernel: ata2: SATA link down (SStatus 4 SControl 300) Dec 7 05:23:36 TheVault kernel: ata3: SATA link down (SStatus 4 SControl 300) Dec 7 05:23:36 TheVault kernel: ata6: SATA link down (SStatus 4 SControl 300) Dec 7 05:23:36 TheVault kernel: ata4: SATA link down (SStatus 4 SControl 300)

Please post the diagnostics: Tools -> Diagnostics

Assuming disk2 is OK and parity is still valid you can try this: -Tools -> New Config -> Retain current configuration: All -> Apply -Check all assignments are correct and assign any missing disk(s) if needed, like old parity and new disk1 -Check both "parity is already valid" and "maintenance mode" and start the array -Stop array -Unassign disk1 -Start array (in normal mode now), ideally the emulated disk will now mount and contents look correct, if it doesn't you should run a filesystem check on the emulated disk -If the emulated disk mounts and contents look correct stop the array -Re-assign disk1 and start array to begin rebuilding.

So disk1 is a new (to the array) disk and disk2 was the one ejected by mistake?

The RAID controller changed the ID of the parity disk, this is one of the reasons we don't recommend using them. Also because of it can see SMART for disks 1 and 2, see if you can get them manually.

Very possibly, try without it.

Looks more like a connection/power problem, if possible try with a different PSU or different backplane.

Unlikely that those SQUASHFS errors are related to the config folder, but you can try booting the current flash with a new config.

3200Mhz is above the max officially supported by your CPU.

Yes. No, any missing disks will be removed from the shares.

Please post the diagnostics: Tools -> Diagnostics P.S.: next time also please use paragraphs when describing a problem, much easier to read.

Remove drives and rebuild parity can be used with any number of removed drives, but any data on those will not be part of the new array.

Yes, 0 is the only acceptable number of sync errors, start here, overclocked RAM with Ryzen is known to corrupt data in some cases.

There were read errors on parity during the rebuild: Dec 6 21:55:38 Elliot kernel: md: disk0 read error, sector=15496560240 Dec 6 21:55:38 Elliot kernel: md: recovery thread: multiple disk errors, sector=15496555488 This means there will be some corruption on the rebuilt disk. Problem was the SATA controller: Dec 6 21:54:07 Elliot kernel: ahci 0000:01:00.1: AMD-Vi: Event logged [IO_PAGE_FAULT domain=0x000d address=0xff4d0000 flags=0x0000] Quite common with Ryzen boards, look for a BIOS update or disable IOMMU if not needed.