JorgeB

Docker image corrupted because it ran out of space, just recreate it.
 
 

No, I mentioned doing a new config: Tools -> New Config, keep all assignments, check parity is already valid before array start, then run a correcting check.

Using a root share will bypass the user shares and make Unraid ignore share settings.

Run a single stream iperf test in both directions to see if it's network related.

Drives are
Formatted with type 2 protection You need to remove this, see below:
https://forums.unraid.net/topic/93432-parity-disk-read-errors/?do=findComment&comment=864078
 

Replacement appears to have been successful, not sure why the error, please reboot and post new diags after array start so I can see the new btrfs scan results.

It's logged as a disk issue, though the disk looks healthy, recommend running an extended SMART test to confirm, if OK just disable spindown for that disk.

Replace the SATA cable for cache1 and post new diags after array start.

Syslog isn't complete, but disks are dropping offline and reconnecting, this is usually a power/connection problem, see if the disks share something in common like a minSAS cable or a power splitter, if not the PSU would be the main suspect.

Apr 6 19:00:28 SkyNet kernel: mpt2sas_cm0 fault info from func: _base_make_ioc_ready Apr 6 19:00:28 SkyNet kernel: mpt2sas_cm0: fault_state(0x6003)! Apr 6 19:00:28 SkyNet kernel: mpt2sas_cm0: sending diag reset !!  
Diags show multiple issues with the HBA like above, make sure it's well seated and sufficiently cooled, you can also try a different PCIe slot if available

With the single profile in btrfs data is written in 1GiB chunks always to the device with most available space, so if or when they have similar available space it will alternate between devices, so a single >1GiB file will always be distributed among them.
 
Basically yes, might as well use raid0, unless using different size devices.
 
Basically what you can't do is add the dropped device if Unraid considers that a new device, since it will be wiped and without it the pool won't mount again, when Unraid thinks it's a new device an "all data on this device will be deleted" warning will appear in front of it, to properly add it you can:
 
-stop the array
-unassign all members from that pool
-start the array so the pool config is "forgotten"
-stop array
-now re-assign all existing pool devices including the one that dropped earlier
-there can't be an "all data on this device will be deleted" warning for any of the devices
-start the array and Unraid will import the existing pool
 

Yep, looks like some form of protection, see if it's this:
 
https://forums.unraid.net/topic/110835-solved-help-with-a-sas-drive/?do=findComment&comment=1011689
 
 
 

You can do that, though it's possible some data fails to copy/move, but at least you'll know which data is affected, another option is to use ddrescue to recover as much as possible.

Problem with the onboard SATA controller, quite common with some Ryzen boards, look for a BIOS update or use an add-on controller (or a different board).

Single parity can't emulate two disks, so no point in trying a filesystem check, you can force enable disk1 to try again to rebuild disk3.
 
This will only work if parity is still valid:
 
-Tools -> New Config -> Retain current configuration: All -> Apply
-Check all assignments and assign any missing disk(s) if needed, including disk3
-IMPORTANT - Check both "parity is already valid" and "maintenance mode" and start the array (note that the GUI will still show that data on parity disk(s) will be overwritten, this is normal as it doesn't account for the checkbox, but it won't be as long as it's checked)
-Stop array
-Unassign disk3
-Start array (in normal mode now), ideally the emulated disk3 will now mount and contents look correct, if it doesn't you should run a filesystem check on the emulated disk or post new diags
-If the emulated disk mounts and contents look correct stop the array
-Re-assign the disk to rebuild and start array to begin.
 
 

Diags are after rebooting so we can't see what happened, disk looks healthy so I would recommend replacing/swapping cables to rule those out then rebuild on top.
 
https://wiki.unraid.net/Manual/Storage_Management#Rebuilding_a_drive_onto_itself

Yes, and there is:
 
Mar 19 20:20:49 IWURSRV kernel: mpt2sas_cm0: mpt3sas_transport_port_remove: removed: sas_addr(0x4433221101000000) Mar 19 20:20:49 IWURSRV kernel: mpt2sas_cm0: removing handle(0x0009), sas_addr(0x4433221101000000) Mar 19 20:20:49 IWURSRV kernel: mpt2sas_cm0: enclosure logical id(0x500605b003cc0de0), slot(2)  
It is a strange issue, since it keeps happening only with those two disks, if it's not power/cable could be a controller or disk problem, can you connect them, even if temporarily, to the onboard SATA ports?
 

Likely the remaining disks are partitioned on sector 2048, instead of Unraid default sector 64.
 
You can check with
fdisk -l /dev/sdX  

Yep, and the test failed, so it should be replaced.

Yep.
 
It must be cleared, not precleared, if you're still rebuilding parity might just do another new config and add the new disk now, this way it will only need formatting.

No.
 
You can set the share use cache setting to "prefer", then run the mover, files can't be in use or they won't be moved.

Do you mean it's unassigned? If yes the right place to ask would be in the existing UD plugin support thread, but you just need to click on it.

Yes, just assign a new parity disk and start the array.

If you're using macvlan for that update to v6.10 and change to ipvlan.

Cache filesystem is corrupt, best bet it to re-format, if there's any important data there you can try these recovery options.