JorgeB

Mover doesn't move data between array drives, you need to do it manually, make sure to always copy/move from disk to disk, never share to disk or disk to share.

Any drive normally added to Unraid will be either rebuilt (if replacing another one) or cleared (if added to a new slot), so any data there will be deleted, not clear to me if that's what you want, to keep the existing data on an added drive you'd need to no a new config and re-sync parity.

Docker image is corrupt, it needs to be recreated, there might be other problems but that's all I can see in the limited log posted, next time please post the diagnostics: Tools -> Diagnostics

Edit config/ident.cfg on the flash drive and change USE_SSL from "yes" to "no", then reboot.

There's no recommended controller to use an eSATA enclosure with port multiplier.

Looks like a disk/compatibility issue: Feb 26 19:43:12 Gidiere kernel: scsi 3:0:0:0: Direct-Access SEAGATE ST2000NXCLAR2000 GS18 PQ: 0 ANSI: 5 Feb 26 19:43:12 Gidiere kernel: scsi 3:0:0:0: SSP: handle(0x0009), sas_addr(0x5000c5006265b725), phy(5), device_name(0x5000c5006265b724) Feb 26 19:43:12 Gidiere kernel: scsi 3:0:0:0: enclosure logical id (0x5c81f660d1ee8800), slot(6) Feb 26 19:43:12 Gidiere kernel: sd 3:0:0:0: Attached scsi generic sg5 type 0 Feb 26 19:43:12 Gidiere kernel: sd 3:0:0:0: [sdf] Read Capacity(16) failed: Result: hostbyte=0x00 driverbyte=0x08 Feb 26 19:43:12 Gidiere kernel: sd 3:0:0:0: [sdf] Sense Key : 0x3 [current] Feb 26 19:43:12 Gidiere kernel: sd 3:0:0:0: [sdf] ASC=0x31 ASCQ=0x0 Feb 26 19:43:12 Gidiere kernel: sd 3:0:0:0: [sdf] Read Capacity(10) failed: Result: hostbyte=0x00 driverbyte=0x08 Feb 26 19:43:12 Gidiere kernel: sd 3:0:0:0: [sdf] Sense Key : 0x3 [current] Feb 26 19:43:12 Gidiere kernel: sd 3:0:0:0: [sdf] ASC=0x31 ASCQ=0x0 Feb 26 19:43:12 Gidiere kernel: sd 3:0:0:0: [sdf] 0 512-byte logical blocks: (0 B/0 B) Feb 26 19:43:12 Gidiere kernel: sd 3:0:0:0: [sdf] 0-byte physical blocks Feb 26 19:43:12 Gidiere kernel: sd 3:0:0:0: [sdf] Write Protect is off Feb 26 19:43:12 Gidiere kernel: sd 3:0:0:0: [sdf] Mode Sense: b7 00 10 08 Feb 26 19:43:12 Gidiere kernel: sd 3:0:0:0: [sdf] Write cache: disabled, read cache: enabled, supports DPO and FUA Feb 26 19:43:12 Gidiere kernel: sd 3:0:0:0: [sdf] Read Capacity(16) failed: Result: hostbyte=0x00 driverbyte=0x08 Feb 26 19:43:12 Gidiere kernel: sd 3:0:0:0: [sdf] Sense Key : 0x3 [current] Feb 26 19:43:12 Gidiere kernel: sd 3:0:0:0: [sdf] ASC=0x31 ASCQ=0x0 Feb 26 19:43:12 Gidiere kernel: sd 3:0:0:0: [sdf] Read Capacity(10) failed: Result: hostbyte=0x00 driverbyte=0x08 Feb 26 19:43:12 Gidiere kernel: sd 3:0:0:0: [sdf] Sense Key : 0x3 [current] Feb 26 19:43:12 Gidiere kernel: sd 3:0:0:0: [sdf] ASC=0x31 ASCQ=0x0 Feb 26 19:43:12 Gidiere kernel: sd 3:0:0:0: [sdf] Attached SCSI disk Do you have a different controller you could try?

9207 is PCIe 3.0, but both should work fine on that board.

It was recognized, but it gave errors immediately, it didn't even mount, different drivers can behave differently when there are issues. Yes to both.

Is the SSD being trimmed at midnight? Trim won't work on that LSI and can cause those errors, which in that case are not a problem, besides the SSD not being trimmed.

Again issues with disk3, since you've already used a different controller/SATA cable try also a different power cable, if issues persist it's likely a disk problem, but because parity is invalid you can't rebuild it, see if you can copy any important data to another disk, failing that try ddrescue.

Yes, many times, possibly super.dat wasn't correctly copied, or there were issues with the flash drive.

It always possible to cause some fs corruption, even when errors are limited to a disk, more likely when multiple disks get affected, but it will also depend if it happens on the middle of write activity, or there were recent writes and all data wasn't flushed to disk.

These are just after a reboot with the array stopped, start the array and the parity sync then post new ones.

https://wiki.unraid.net/Troubleshooting#Re-enable_the_drive

No, removing the disk after formatting would need a pairity re-sync, there wouldn't be many errors, but there would be some, and a single error is one too many.

That was unavoidable, once a disk gets disable it needs to be rebuilt, you can re-enable the disk now or if you plan on replacing the controller soon do it after that.

No danger, it will create a new empty filesystem that can be used immediately.

Parity is calculated sector by sector, no data or empty doesn't mean anything, only if all the disks were cleared (or precleared) and all zeros can you safely use parity is already valid.

Please post new diags.

If Unraid did a parity after a reboot it means there was an unclean shutdown and you should let it finish, and if you want to avoid it the only is doing a new config and checking "parity is already" valid before starting the array, but you risk being left with invalid parity in case of a disk failure.

SFF-8643 to SFF-8088 cable + SFF-8088 to SFF-8087 adapter

Looking again at the original diags it's possible, even probable, that disk3 is really having issues, but before and because of the port multiplier the problem appeared to be on multiple disks, all the ones connected to the same port.

There's a problem with disk3: Feb 26 15:06:30 Tower kernel: mpt2sas_cm0: log_info(0x31110d00): originator(PL), code(0x11), sub_code(0x0d00) Feb 26 15:06:30 Tower kernel: sd 1:0:6:0: [sdl] tag#1698 UNKNOWN(0x2003) Result: hostbyte=0x00 driverbyte=0x08 Feb 26 15:06:30 Tower kernel: sd 1:0:6:0: [sdl] tag#1698 Sense Key : 0x2 [current] Feb 26 15:06:30 Tower kernel: sd 1:0:6:0: [sdl] tag#1698 ASC=0x4 ASCQ=0x0 Feb 26 15:06:30 Tower kernel: sd 1:0:6:0: [sdl] tag#1698 CDB: opcode=0x88 88 00 00 00 00 00 ae a8 a8 58 00 00 01 08 00 00 Feb 26 15:06:30 Tower kernel: print_req_error: I/O error, dev sdl, sector 2930288728 Feb 26 15:06:30 Tower kernel: md: disk3 read error, sector=2930288664 Feb 26 15:06:30 Tower kernel: md: disk3 read error, sector=2930288672 Feb 26 15:06:30 Tower kernel: md: disk3 read error, sector=2930288680 Feb 26 15:06:30 Tower kernel: md: disk3 read error, sector=2930288688 Feb 26 15:06:30 Tower kernel: md: disk3 read error, sector=2930288696 Feb 26 15:06:30 Tower kernel: md: disk3 read error, sector=2930288704 Start by replacing/swapping cables.

Any Intel gigabit NIC is fine.