JorgeB

Probably the easiest way.

After that is done you still need to do a new config and resync parity.

Then unassign it again, start the array and copy/move all data from disk8 to the array, Unraid never moves data from one array disk to another, you can use your favourite tool or for example the Unbalance plugin.

Don't know what guide you were seeing but that's not correct, doing that will start the array with the missing disk emulated, and what you did after will rebuild the same disk on top. Disk8 does appear to have some issues, if you still want to removed it from the array you need to do a new config and re-sync parity, is there still any data on that disk?

Please post the diagnostics: Tools -> Diagnostics

Please don't double post, already replied on the other thread.

Disk doesn't have any partitions, so no data.

Please post the diagnostics: Tools -> Diagnostics

That release no longer exists in the cloud, you can upgrade to latest manually or using the plugin mentioned on the release notes, also see this:

Disk appears to be failing, you can confirm by running an extended SMART test.

Cache filesystem is corrupt, best way forward is to backup, re-format and restore cache data.

Do that and post new diags if there are more sync errors.

That's not a problem.

I checked the newest diags and there was only one check logged.

Is that error from FCP? If yes best to post in the plugin support thread together with the diagnostics.

Also see this, overclock RAM is known to cause stability issues (even data corruption).

Enable mover logging, run the mover, post new diags and mention the share name you're trying to move.

Flash drive is dropping out, you appear to be using a USB 3.0 port, if yes try a USB 2.0 port instead, 3.0 is not recommended.

See the FAQ: https://forums.unraid.net/topic/46802-faq-for-unraid-v6/?do=findComment&comment=480417

No, not normal, look for a stock firmware from Seagate, other than that don't have other ideas.

Yes, in the previous diags the problem started with sdf (device 7:0:4:0) but ended up causing issues with other disks, in this example devices 7:0:1:0 and 7:0:4:0: Apr 11 17:03:34 Tower kernel: sd 7:0:4:0: [sdf] tag#935 UNKNOWN(0x2003) Result: hostbyte=0x00 driverbyte=0x08 Apr 11 17:03:34 Tower kernel: sd 7:0:4:0: [sdf] tag#935 Sense Key : 0x2 [current] [descriptor] Apr 11 17:03:34 Tower kernel: sd 7:0:4:0: [sdf] tag#935 ASC=0x4 ASCQ=0x11 Apr 11 17:03:34 Tower kernel: sd 7:0:4:0: [sdf] tag#935 CDB: opcode=0x88 88 00 00 00 00 01 d1 c0 be 00 00 00 00 08 00 00 Apr 11 17:03:34 Tower kernel: print_req_error: I/O error, dev sdf, sector 7814036992 Apr 11 17:03:34 Tower kernel: sd 7:0:4:0: [sdf] tag#935 UNKNOWN(0x2003) Result: hostbyte=0x00 driverbyte=0x08 Apr 11 17:03:34 Tower kernel: sd 7:0:4:0: [sdf] tag#935 Sense Key : 0x2 [current] [descriptor] Apr 11 17:03:34 Tower kernel: sd 7:0:4:0: [sdf] tag#935 ASC=0x4 ASCQ=0x11 Apr 11 17:03:34 Tower kernel: sd 7:0:4:0: [sdf] tag#935 CDB: opcode=0x88 88 00 00 00 00 01 d1 c0 be 00 00 00 00 08 00 00 Apr 11 17:03:34 Tower kernel: print_req_error: I/O error, dev sdf, sector 7814036992 Apr 11 17:03:34 Tower kernel: Buffer I/O error on dev sdf, logical block 976754624, async page read Apr 11 17:03:46 Tower kernel: sd 7:0:1:0: device_block, handle(0x000a) Apr 11 17:03:47 Tower kernel: sd 7:0:1:0: device_unblock and setting to running, handle(0x000a) Apr 11 17:03:50 Tower kernel: sd 7:0:4:0: [sdf] tag#1764 UNKNOWN(0x2003) Result: hostbyte=0x0b driverbyte=0x00 Apr 11 17:03:50 Tower kernel: sd 7:0:4:0: [sdf] tag#1764 CDB: opcode=0x85 85 06 20 00 00 00 00 00 00 00 00 00 00 40 e5 00 Apr 11 17:03:50 Tower kernel: mpt2sas_cm0: log_info(0x31120100): originator(PL), code(0x12), sub_code(0x0100) Apr 11 17:03:50 Tower kernel: sd 7:0:4:0: [sdf] tag#1764 UNKNOWN(0x2003) Result: hostbyte=0x0b driverbyte=0x00 Apr 11 17:03:50 Tower kernel: sd 7:0:4:0: [sdf] tag#1764 CDB: opcode=0x85 85 06 20 00 00 00 00 00 00 00 00 00 00 40 98 00 Apr 11 17:03:50 Tower kernel: mpt2sas_cm0: log_info(0x31120100): originator(PL), code(0x12), sub_code(0x0100) ### [PREVIOUS LINE REPEATED 2 TIMES] ### Apr 11 17:03:50 Tower kernel: sd 7:0:4:0: device_block, handle(0x000d) Apr 11 17:03:51 Tower kernel: sd 7:0:4:0: device_unblock and setting to running, handle(0x000d) Apr 11 17:03:53 Tower kernel: sd 7:0:4:0: Power-on or device reset occurred Apr 11 17:03:57 Tower kernel: sd 7:0:1:0: device_block, handle(0x000a) Apr 11 17:03:58 Tower kernel: sd 7:0:1:0: device_unblock and setting to running, handle(0x000a) Apr 11 17:04:16 Tower kernel: sd 7:0:3:0: device_block, handle(0x000c) Apr 11 17:04:16 Tower kernel: sd 7:0:4:0: device_block, handle(0x000d) Apr 11 17:04:18 Tower kernel: sd 7:0:3:0: device_unblock and setting to running, handle(0x000c) Apr 11 17:04:18 Tower kernel: sd 7:0:4:0: device_unblock and setting to running, handle(0x000d) Apr 11 17:04:18 Tower kernel: sd 7:0:4:0: Power-on or device reset occurred Apr 11 17:04:20 Tower kernel: sd 7:0:1:0: device_block, handle(0x000a) Apr 11 17:04:21 Tower kernel: sd 7:0:1:0: device_unblock and setting to running, handle(0x000a) Apr 11 17:04:28 Tower kernel: sd 7:0:4:0: device_block, handle(0x000d) Apr 11 17:04:29 Tower kernel: sd 7:0:4:0: device_unblock and setting to running, handle(0x000d) Apr 11 17:04:30 Tower kernel: sd 7:0:4:0: Power-on or device reset occurred Apr 11 17:04:31 Tower kernel: sd 7:0:3:0: device_block, handle(0x000c) Apr 11 17:04:32 Tower kernel: sd 7:0:3:0: device_unblock and setting to running, handle(0x000c) Apr 11 17:04:33 Tower kernel: sd 7:0:1:0: device_block, handle(0x000a) Apr 11 17:04:35 Tower kernel: sd 7:0:1:0: device_unblock and setting to running, handle(0x000a)

All disk related errors are gone at least for now, even for the other disks, I would suggest running it like that for a couple of days.

Ohh, and for the other question see: https://wiki.unraid.net/Un-Official_UnRAID_Manual#High_Water

Unlikely to be a disk problem since just before the read errors there where issues with multiple disks: Apr 11 13:15:45 Tower kernel: sd 4:0:1:0: [sdi] tag#93 Sense Key : 0x1 [current] Apr 11 13:15:45 Tower kernel: sd 4:0:1:0: [sdi] tag#93 ASC=0x18 ASCQ=0x7 Apr 11 14:24:19 Tower kernel: sd 4:0:1:0: [sdi] tag#28 Sense Key : 0x1 [current] Apr 11 14:24:19 Tower kernel: sd 4:0:1:0: [sdi] tag#28 ASC=0x18 ASCQ=0x7 Apr 11 15:19:49 Tower kernel: sd 4:0:1:0: [sdi] tag#27 Sense Key : 0x1 [current] Apr 11 15:19:49 Tower kernel: sd 4:0:1:0: [sdi] tag#27 ASC=0x18 ASCQ=0x7 Apr 11 15:34:50 Tower kernel: sd 4:0:1:0: [sdi] tag#20 Sense Key : 0x1 [current] Apr 11 15:34:50 Tower kernel: sd 4:0:1:0: [sdi] tag#20 ASC=0x18 ASCQ=0x7 Apr 11 15:34:51 Tower kernel: sd 4:0:1:0: [sdi] tag#18 Sense Key : 0x1 [current] Apr 11 15:34:51 Tower kernel: sd 4:0:1:0: [sdi] tag#18 ASC=0x18 ASCQ=0x2 Apr 11 15:41:34 Tower kernel: sd 4:0:1:0: [sdi] tag#66 Sense Key : 0x1 [current] Apr 11 15:41:34 Tower kernel: sd 4:0:1:0: [sdi] tag#66 ASC=0x18 ASCQ=0x7 Apr 11 15:41:50 Tower kernel: sd 4:0:1:0: [sdi] tag#104 Sense Key : 0x1 [current] Apr 11 15:41:50 Tower kernel: sd 4:0:1:0: [sdi] tag#104 ASC=0x18 ASCQ=0x7 Apr 11 15:42:02 Tower kernel: sd 4:0:1:0: [sdi] tag#96 Sense Key : 0x1 [current] Apr 11 15:42:02 Tower kernel: sd 4:0:1:0: [sdi] tag#96 ASC=0x18 ASCQ=0x7 Apr 11 15:54:02 Tower kernel: sd 4:0:11:0: [sds] tag#28 Sense Key : 0x1 [current] Apr 11 15:54:02 Tower kernel: sd 4:0:11:0: [sds] tag#28 ASC=0x18 ASCQ=0x7 Apr 11 15:54:02 Tower kernel: sd 4:0:11:0: [sds] tag#120 Sense Key : 0x1 [current] Apr 11 15:54:02 Tower kernel: sd 4:0:11:0: [sds] tag#120 ASC=0x18 ASCQ=0x7 Apr 11 15:54:02 Tower kernel: sd 4:0:7:0: [sdo] tag#46 Sense Key : 0x1 [current] Apr 11 15:54:02 Tower kernel: sd 4:0:7:0: [sdo] tag#46 ASC=0x18 ASCQ=0x7 Apr 11 15:54:02 Tower kernel: sd 4:0:7:0: [sdo] tag#57 Sense Key : 0x1 [current] Apr 11 15:54:02 Tower kernel: sd 4:0:7:0: [sdo] tag#57 ASC=0x18 ASCQ=0x7 Apr 11 15:54:03 Tower kernel: sd 4:0:3:0: [sdk] tag#30 Sense Key : 0x1 [current] Apr 11 15:54:03 Tower kernel: sd 4:0:3:0: [sdk] tag#30 ASC=0x18 ASCQ=0x7 Apr 11 15:54:51 Tower kernel: sd 4:0:7:0: [sdo] tag#118 Sense Key : 0x1 [current] Apr 11 15:54:51 Tower kernel: sd 4:0:7:0: [sdo] tag#118 ASC=0x18 ASCQ=0x7 Apr 11 16:25:03 Tower kernel: sd 4:0:13:0: [sdu] tag#57 Sense Key : 0x1 [current] Apr 11 16:25:03 Tower kernel: sd 4:0:13:0: [sdu] tag#57 ASC=0x18 ASCQ=0x7 Apr 11 16:25:18 Tower kernel: sd 4:0:7:0: [sdo] tag#5 Sense Key : 0x1 [current] Apr 11 16:25:18 Tower kernel: sd 4:0:7:0: [sdo] tag#5 ASC=0x18 ASCQ=0x7 Apr 11 16:25:19 Tower kernel: sd 4:0:11:0: [sds] tag#8 Sense Key : 0x1 [current] Apr 11 16:25:19 Tower kernel: sd 4:0:11:0: [sds] tag#8 ASC=0x18 ASCQ=0x7 Apr 11 16:33:04 Tower kernel: sd 4:0:1:0: [sdi] tag#96 Sense Key : 0x1 [current] Apr 11 16:33:04 Tower kernel: sd 4:0:1:0: [sdi] tag#96 ASC=0x18 ASCQ=0x7 Apr 11 16:42:48 Tower kernel: sd 4:0:1:0: [sdi] tag#62 UNKNOWN(0x2003) Result: hostbyte=0x00 driverbyte=0x08 Apr 11 16:42:48 Tower kernel: sd 4:0:1:0: [sdi] tag#62 Sense Key : 0x3 [current] Apr 11 16:42:48 Tower kernel: sd 4:0:1:0: [sdi] tag#62 ASC=0x11 ASCQ=0x0 Apr 11 16:42:48 Tower kernel: sd 4:0:1:0: [sdi] tag#62 CDB: opcode=0x28 28 00 00 4f 89 e8 00 04 00 00 Apr 11 16:42:48 Tower kernel: print_req_error: critical medium error, dev sdi, sector 5213055 Apr 11 16:42:48 Tower kernel: md: disk12 read error, sector=5212984 Check if these disks share anything in common besides the controller, since not all disks there were affected.

Sdf which appears the most problematic is using a different firmware, hence why I suggest disconnecting that one first. Sorry no, you'd need to search for a stock Seagate firmware for that model that may or not be flashable.