JorgeB

Based on the syslog disk5 appears to be failing but it would be good to see the SMART report, power down check connections, power back on and if it comes back online post a SMART report: smartctl -x /dev/sdX > /boot/disk5.txt

It failed both short and extended SMART tests, that's a pretty serious issue, disk needs to be replaced.

Try on a different device, a regular HDD, if still slow post diags downloaded during the transfer.

Don't see anything out of the ordinary on the logs.

Same problem as before, looks like an issue with this kernel release and the LSI on your board, but can't tell you were the fault is, the board, the kernel or the LSI driver.

Did you try v6.8.1?

That means it's one of the plugins, maybe network starts, make sure all are up to date and it still errors uninstall one a a time.

Current rebuild will be corrupt, not much point in continuing, please post syslog and SMART report for disk5.

That's likely from a plugin, try safe mode.

Use -a (archive) instead of -r, it includes -r and a lot of other good options, -u seems appropriate if there are newer files with the same name you want to keep on dest, also like to use -v, so -auv, you can run a dry run by adding -n (-nauv) first to make sure it's going to do what you want.

Is that with all docker/VMs stopped? If yes it's likely a hardware problem, if not try just using it without anything else running for a couple of days.

There are general protection errors, start by running memtest, you can also try safe mode.

Changed Status to Closed

Changed Status to Open Changed Priority to Other

This looks like a general support issue, please continue discussion here:

You can copy from UD to user or disk share, parity will always be maintained.

Parity and disk3 dropped offline almost immediatly after array start: Jan 14 00:44:27 TowerPAPA kernel: ata4: link is slow to respond, please be patient (ready=0) Jan 14 00:44:32 TowerPAPA kernel: ata4: device not ready (errno=-16), forcing hardreset Jan 14 00:44:37 TowerPAPA kernel: ata4: link is slow to respond, please be patient (ready=0) Jan 14 00:44:42 TowerPAPA kernel: ata4: SRST failed (errno=-16) Jan 14 00:44:47 TowerPAPA kernel: ata4: link is slow to respond, please be patient (ready=0) Jan 14 00:44:52 TowerPAPA kernel: ata4: SRST failed (errno=-16) Jan 14 00:44:57 TowerPAPA kernel: ata4: link is slow to respond, please be patient (ready=0) Jan 14 00:45:27 TowerPAPA kernel: ata4: SRST failed (errno=-16) ### [PREVIOUS LINE REPEATED 1 TIMES] ### Jan 14 00:45:32 TowerPAPA kernel: ata4: reset failed, giving up Jan 14 00:45:32 TowerPAPA kernel: ata4.00: disabled Jan 14 00:45:32 TowerPAPA kernel: ata4.01: disabled And a few minutes later disk1 and disk2 did the same: Jan 14 00:53:51 TowerPAPA kernel: ata3: link is slow to respond, please be patient (ready=0) Jan 14 00:53:56 TowerPAPA kernel: ata3: device not ready (errno=-16), forcing hardreset Jan 14 00:54:01 TowerPAPA kernel: ata3: link is slow to respond, please be patient (ready=0) Jan 14 00:54:06 TowerPAPA kernel: ata3: SRST failed (errno=-16) Jan 14 00:54:11 TowerPAPA kernel: ata3: link is slow to respond, please be patient (ready=0) Jan 14 00:54:16 TowerPAPA kernel: ata3: SRST failed (errno=-16) Jan 14 00:54:21 TowerPAPA kernel: ata3: link is slow to respond, please be patient (ready=0) Jan 14 00:54:51 TowerPAPA kernel: ata3: SRST failed (errno=-16) ### [PREVIOUS LINE REPEATED 1 TIMES] ### Jan 14 00:54:56 TowerPAPA kernel: ata3: reset failed, giving up Jan 14 00:54:56 TowerPAPA kernel: ata3.00: disabled Jan 14 00:54:56 TowerPAPA kernel: ata3.01: disabled Rebooting should bring them back online, but there's likely a power/board issue, also controller is set to IDE but I believe that board doesn't support AHCI, if it does change it.

Trim doesn't work currently on LSI SAS2 models, but even if it did it wouldn't work on that SSD, LSI requires SSDs with deterministic read zeros after trim, so you should connect it to an onboard SATA port instead.

Errors are from the docker image running out of space on cache, it should be fine once space is freed, if not just re-create it.

To erase bios you can use: sas2flash -o -e 5 It can be flashed later at anytime if needed.

You only need a bios if you want to boot from a connected device, and that's never needed with Unraid.

Cache has plenty of space, and unrelated to your issue, it's not redundant because of this bug.

Like mentioned you don't really need a bios, but if you want to update: sas2flsh.exe -o -b MPTSAS2.ROM

fstrim -v /mnt/cache or fstrim -v /path/to/mount/point

First try re-creating flash drive after backing up the config folder and then restore, so all config is kept, if still issues try with a trial flash, if that boots you need to re-create your config, you can still keep disk assignments (super.dat) and key, then just restore parts of the config a little at a time to see where the problem was or just reconfigure the server.