JorgeB

Don't see any issue logged on the Unraid side, can you access the flash drive over SMB if you enable that?

I don't see any sync errors logged.

Do you mean no post or no video after Unraid boots?

The only thing I've asked for was the persistent sylog from the syslog server after the issue occurs; see the link for how to enable that and set it to be saved to a share, then post that, it will log the time codes.

shfs was just the victim; you need to figure out what caused the OOM, a container like mentioned is a good suspect.

All the disks are dropping offline. My first recommendation would be to update the LSI firmware; if that doesn't help, see if there are any issues with spin-down disabled.

Yep, you need to do a new config and then resync parity -Tools -> New Config -> Preserve current assignments: All -> Apply Then assign the new data disk and start the array

Jul 6 18:25:49 unraid kernel: fat__get_entry: 891 callbacks suppressed Jul 6 18:25:49 unraid kernel: FAT-fs (sdf1): Directory bread(block 32316) failed Jul 6 18:25:49 unraid kernel: FAT-fs (sdf1): Directory bread(block 32317) failed Jul 6 18:25:49 unraid kernel: FAT-fs (sdf1): Directory bread(block 32318) failed Jul 6 18:25:49 unraid kernel: FAT-fs (sdf1): Directory bread(block 32319) failed Jul 6 18:25:49 unraid kernel: FAT-fs (sdf1): Directory bread(block 32320) failed Flash drive problem: you can try backup and recreate first; if the issues persist, replace it.

Disks 4 and 7 currently.

Post the approximate date and time you last experienced the issues to see if there's anything logged.

Disk was already disabled at boot, so we can't see what happened, SMART looks fine, so check/replace cables and resync parity. https://docs.unraid.net/unraid-os/using-unraid-to/manage-storage/array/replacing-disks-in-array/#re-enabling-a-disabled-disk-rebuilding-onto-itself

Yep, and if all disks mount now, check their contents; also post new diags.

Run without -n , and again if it asks for -L use it

Those errors can be intermittent; that is, the data is returned correctly on a retry; otherwise, you should get an i/o error. Devices should never return bad data, unless there's a firmware bug.

They are logged as disk failures, and SMART doesn't look good; cancel the rebuild and run an extended SMART test on both.