JorgeB

You can still use Windows, can also use for example midnight commander (mc on the console), important part it to only transfer from user share to user share, or disk share to disk share.

Yep.

Yes, depending on Unraid release you might need to check a box before array start.

Docker image can easily be recreated, and probably best than re-using existing one, but if you it it should be put in: DOCKER_IMAGE_FILE="/mnt/user/system/docker/docker.img" libvirt: IMAGE_FILE="/mnt/user/system/libvirt/libvirt.img" virtio iso: VIRTIOISO="/mnt/user/isos/virtio-win-0.1.190-1.iso" Make sure docker and VM services are stopped before doing it.

Why not? It should... You can do a new config, then check "parity is already valid" before array start and run a parity check.

Yes, if everything important there is backed up.

Difficult to say without starting swapping things around, I would start with board/CPU.

Logs are spammed with docker messages and rotated, can't see initial boot info and the LSI firmware, make sure it's using the latest one, 20.00.07.00, other p20 releases especially have known issues, other than that you can try disabling spin down to see if it helps, even if it's for that disk only.

See link above.

If that's correct then it's a good option.

You should use a HBA, see here for some recommendations:

That looks like a MegaRAID clone, it might not be flashable to IT mode, but no personal experience with that model, you can google it.

No good reason to not use the recommended ports, unless there was some cable length/management related issue, but any port should work.

Logged call traces look more like hardware related, not the macvlan/nf_nat 6.9.x related crashes.

Do you mean you stopped the server and it rebooted on it's own? If yes that's a hardware problem, I do see some hardware issues logged: Jun 9 02:27:34 Vault001 kernel: mce: [Hardware Error]: Machine check events logged Jun 9 02:27:34 Vault001 kernel: [Hardware Error]: Corrected error, no action required. Jun 9 02:27:34 Vault001 kernel: [Hardware Error]: CPU:0 (17:71:0) MC27_STATUS[-|CE|MiscV|-|-|-|SyndV|-|-|-]: 0x982000000002080b Jun 9 02:27:34 Vault001 kernel: [Hardware Error]: IPID: 0x0001002e00000500, Syndrome: 0x000000005a020001 Jun 9 02:27:34 Vault001 kernel: [Hardware Error]: Power, Interrupts, etc. Ext. Error Code: 2, Link Error. Jun 9 02:27:34 Vault001 kernel: [Hardware Error]: cache level: L3/GEN, mem/io: IO, mem-tx: GEN, part-proc: SRC (no timeout) Looks like they are CPU cache related.

Assuming you copied the data directly to the disk, i.e., without using a specif folder or share and it's now together with the data that already existed on that disk I would remove the disk from the array, then run rsync again but now from an unassign disk to the array, you'll need to do it multiple times if there are multiple shares on source, but it will start where it left of, i.e., just copy whatever is missing, and since the array is now the dest no issues with space.

Try deleting/renaming vfio-pci.cfg from flash drive to see if it boots.

If you installed mcelog any more errors should be logged in the syslog.

Corruption was detected on the cache filesystem and it went read-only: Jun 8 07:29:47 tower1 kernel: BTRFS error (device dm-3): block=1041472405504 write time tree block corruption detected Jun 8 07:29:47 tower1 kernel: BTRFS: error (device dm-3) in btrfs_commit_transaction:2377: errno=-5 IO failure (Error while writing out transaction) Jun 8 07:29:47 tower1 kernel: BTRFS info (device dm-3): forced readonly You should backup and restore data, docker image should then be recreated.

There are read errors with multiple disks, first thing to do is to update the LSI firmware, all p20 releases except latest one (20.00.07.00) have known issues.

Reboot and post new diags as soon as it happens again.

NVMe device dropped, this can sometimes help with that: Some NVMe devices have issues with power states on Linux, try this, on the main GUI page click on flash, scroll down to "Syslinux Configuration", make sure it's set to "menu view" (on the top right) and add this to your default boot option, after "append initrd=/bzroot" nvme_core.default_ps_max_latency_us=0 e.g.: append initrd=/bzroot nvme_core.default_ps_max_latency_us=0 Reboot and see if it makes a difference, also good idea to look for a board BIOS update.

Diags after rebooting are not much help for this, you can try enabling syslog mirror to flash then post that log after a crash.

Than you likely have some plugin or other issue keeping the drives from spinning down, note that a frequent low number of reads is normal when the drives are up to get SMART/temp, but these shouldn't prevent them from spinning down.

That's a good option and that model originally was IT mode only, so no flashing needed unless someone converted it to an IR model. Should be a good combo, and good for roughly 220MB/s with 20 drives on the expander. Yep.