JorgeB

It's logged as a disk problem, you should run an extended SMART test.

Run another check, if there are more errors post new diags.

Not that uncommon for a disk to "disintegrate" when moving it after many hours of use in the same place, even if you are careful.

Crash appears to be network related, try to simplify your config as much as possible, also don't assign a custom IP to dockers.

Try backing up and recreating the flash drive.

Not sure, but don't think so.

Yep.

You could use this and then do smartctl -A after for the IO. This works for me. Basically you need to run a script that does: /usr/local/sbin/sdspin /dev/sdX up /usr/sbin/smartctl -A /dev/sdX Where X is replaced with the different array devices, ideally the script should get the device list from the array, since sdX can change when new controllers/devices are added, sometimes it even changes without any new ones, I'm not really a script guy, but it should be easy the get them, if not you can always do it manually, but need to be aware that they can change.

Good idea.

Settings - disk settings - shutdown timeout Try 100 secs or similar just to save the new value.

I saw that but that by itself it's not a big deal, but If you're sure they weren't there before the move run an extended SMART test, if it passes try again, if it doesn't replace.

Not clear to me if you plan on using the new cloned disk as disk3, if yes you'd do a new config with it and re-sync parity, all data on there will be part of the array, if you plan to use another disk for disk3 than you'd need to replace and rebuild, then format (since it would still be unmountable) and then copy the data from the cloned disk to the array using UD.

Strange, it appears to be timing out just after a couple of seconds, and shutdown timeout is set to 90 secs, try changing that value and re-applying.

Disk dropped offline and reconnect again, this is usually a connection/power, check/replace cables and try again.

I guess another thing I can use is instead of just running the spin up script as I was doing before, change it to use sdspin <device> up and then run another script with sdspin <device> down, this achieves what I need.

When this happens Unraid saves the diags in the flash drive, those could give a clue on what's causing it.

This means an unclean shutdown, when this happens Unraid saves the diags in the flash drive, those could give a clue on what's causing it.

Looks fine, but I only use -f. No, you'd need to do a new config and re-sync parity.

Correct. Thanks, worth a try.

Unless you're going to use them with SSDs there's enough bandwidth, see here:

This works to spin up the disk, but it doesn't update the GUI status, so the disk won't spin down again.

I mean clone old disk3 (not the emulated disk) with ddrescue.

Disk1 dropped offline so there's no SMART, but this is usually not a disk problem, check/replace cables, could also be a power problem.

The errors were not on the parity drive, though they are more likely to happen during a parity sync due to the heavy IO, do the errors happen to any disk on the different controllers? Maybe they are limited to a controller or backplane?

Disk dropped offline, if the emulated disk is mounting and contents look correct you can rebuild on top.