JorgeB

Did you look at the link, it's still way above max AMD supported speeds, so it's an overclock, and known to corrupt data in some cases, even if no errors are detected with memtest.

You have two disabled disks and parity2 is failing, so not a good spot, disks 2 and 4 look healthy, but disk2 is now corrupt, you could re-enable disk4, assuming it's OK and try again to rebuild disk2, though some sync errors will still exist.

There are several crashes, possibly RAM related, see here, you're overclocking the RAM and that is a known issue with those CPUs, but after fixing that also good to recreate the docker image.

When this happens again download diagnostics (tools -> diagnostics) before rebooting and attach them here.

https://forums.unraid.net/topic/46802-faq-for-unraid-v6/?do=findComment&comment=480421

Yep.

Are you looking for RJ45 or SFP+? Mellanox ConnectX-2/3 and Intel are good options for SFP+, Intel and Aquantia for RJ45.

Are you using a USB 2.0 port? Full diags might also give more clues, or this after the problems start.

Try to copy the config folder.

There's a lot of crashing, unfortunately not seeing the reason, but most likely hardware related.

Don't see any errors on the log, are you using NFS? If yes try with SMB instead if possible.

See here: https://forums.unraid.net/topic/46802-faq-for-unraid-v6/?do=findComment&comment=700582

Oct 22 14:34:50 VM kernel: be2net 0000:0a:00.0 eth4: Link is Down Oct 22 14:34:50 VM kernel: be2net 0000:0a:00.1 eth5: Link is Up One of the ports appears to be up, are you using the right port?

If there's no data there it's gone, maybe you formatted it again? The docker image would be re-created by Unraid.

What controller do you have? The only one I'm seeing in the diags is the Intel SATA controller, and one one has nothing connected: Oct 22 12:23:11 Tower kernel: ata6: SATA link down (SStatus 0 SControl 300) Oct 22 12:23:11 Tower kernel: ata5: SATA link down (SStatus 0 SControl 300) Oct 22 12:23:11 Tower kernel: ata2: SATA link down (SStatus 0 SControl 300) Oct 22 12:23:11 Tower kernel: ata4: SATA link down (SStatus 0 SControl 300) Oct 22 12:23:11 Tower kernel: ata3: SATA link down (SStatus 0 SControl 300) Oct 22 12:23:11 Tower kernel: ata1: SATA link down (SStatus 0 SControl 300)

Make sure you're using the correct "Power Supply Idle Control" setting.

If you are sure of the current configuration just do a new config, assign all disks to where they should be and check "parity is already valid" before starting the array.

IRQ16 got disable, and it appears to be the one used by the controller where the flash drive is, you could try the other USB controller.

This.

You're copying from/to the same device, that's not a good way to test.

Please post output of: blkid and fdisk -l /dev/sdd

Yes, you're right of course, my bad, only looked at the driver and that driver can be used for USB 3.0 but also 2.0 on older boards, you can still try the other USB controller controller, it uses a different driver, though any Intel USB 2.0 port usually works OK.

This is while the transfer is being cached to RAM, no SATA device can read/write at those speeds. This would be the normal speed that device should sustain during writes. Doesn't look normal at all, also likely unrelated to temps, as 43C is nothing for an SSD during writes.

No, cache defaults to btrfs. Stop array, click on it, change fs to xfs, start array, format.

That sounds like a flash drive dropping issue, since you're using a USB 3.0 port and those are not recommended try a 2.0 one, you can also do this, and if it happens again post that log.