JorgeB

Need to see the logs from those.

Mover doesn't do that, it only moves from cache to array or array to cache, appdata is set to shareUseCache="prefer", so it's trying to move from the array to cache.

Mover won't replace any existing files.

Looks more like a power/connection problem, check/replace both cables.

If you hadn't run a parity check it would likely be much easier to recover, check filesystem on disk3, it might still be salvageable.

I forgot to mention, GUI tests only work for SATA devices, you need to run it manually (make sure disk spin down is disable if you have the SAS spin down plugin): smartctl -t long /dev/sdX

Running a parity check wasn't the best option since parity will be updated, since the disks were still mounting first thing is to make sure backups are up to date. Diags posted don't show issues with disk3, should post new ones.

At least 1 pass, ideally 24H.

Please post the diagnostics to see the actual array status.

Try running memtest, post read can fail if drives return non zeros on read, that can happen with bad RAM.

You can use the parity swap procedure.

Buy the license for the new flash drive and copy the config folder from the old one, you can deleted trial.key.

Hopefully but unlikely, if it continues to crash you can try 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.

That's normal since cache is a single device and not redundant.

No, that means something is sending the shutdown command to Unraid. Star by running in safe mode to rule out the plug-ins.

Some sync errors are expected because of what happened, just let it finish, like mentioned by itimpi you can then run a non correcting check if you want to confirm all is fine, and it should be.

Nothing obvious, are you still using any hardware from the old build, like PSU, RAM, etc?

That usually means something is interrupting the test, should not be controller related.

Disable disk spin down and try again.

Vendor Specific SMART Attributes with Thresholds: ID# ATTRIBUTE_NAME FLAGS VALUE WORST THRESH FAIL RAW_VALUE 1 Raw_Read_Error_Rate POSR-K 200 200 051 - 4161 5 Reallocated_Sector_Ct PO--CK 199 199 140 - 39 196 Reallocated_Event_Count -O--CK 193 193 000 - 7 197 Current_Pending_Sector -O--CK 200 200 000 - 2 198 Offline_Uncorrectable ----CK 200 200 000 - 3 200 Multi_Zone_Error_Rate ---R-- 200 200 000 - 177 All these are bad, they should all be 0, though some are more serious than others, you can run an extended SMART test to confirm since there's no recent one, but would be surprised if it passed, if you do it disable spin sown before starting the test.

SMART looks fine, like mentioned above looks more like a power/connection problem, but you can run a SMART long test to confirm.

It's logged as a disk problem and SMART shows several issues, you should replace it. You should enable system notifications to get notified immediatly when there's a problem, or it could be too late when you find it.

Nothing logged before the crash, could be a hardware issue, log does show data corruption being detected in one of the cache devices, you should run a scrub to see if all errors are fixable and monitor the pool for further errors, more info here.

SMART is showing some issues, also logged the read error, you should run an extended SMART test.

Enable the syslog server and post that after a crash.