JorgeB

Should be fine, and you can always upgrade back to v6.7 if needed, LT is trying to fix this issue for v6.8rc1, which will hopefully be released soon will be released soon™

You can do a new config and checking "parity is already valid" before starting the array.

Disable that attribute just for the cache drive, SSDs usually don't really get pending sectors anyways, but you want to keep monitoring your disks.

Try re-enabling it again, if errors persist you'll need to wait for somebody else's help as SSL issues are outside my wheelhouse.

You can try disabling SSL and if it works then try re-enabling, edit config/ident.cfg on the flash drive and change USE_SSL from "yes" to "no", then reboot.

Not sure since there aren't any errors logged and you're the only one having this issue, maybe try v6.8 that will be released soon, newer kernel might make a difference.

If it's an HP server there's a fix for that.

Enclosure uses a SATA port multiplier and those are not recommended, though some combinations work, IMHO if you need external get SAS.

They are known to run hot, since they are designed for servers, so a fan blowing some air directly on the heat sink is highly recommended, it can be a side fan, below, directly on top of the heat synk, etc.

No, you need to use the invalidslot command, follow the instructions below carefully: -Tools -> New Config -> Retain current configuration: All -> Apply -Assign any missing disk(s), like both parity disks (command below needs both parity disks assigned, it's different with just single parity) and new disk3 -Important - After checking the assignments leave the browser on that page, the "Main" page. -Open an SSH session/use the console and type (don't copy/paste directly from the forum, as sometimes it can insert extra characters): mdcmd set invalidslot 3 -Back on the GUI and without refreshing the page, just start the array, do not check the "parity is already valid" box (GUI will still show that data on parity disk(s) will be overwritten, this is normal as it doesn't account for the invalid slot command, but they won't be as long as the procedure was correctly done), disk3 will start rebuilding, disk may or not mount immediately but if it's unmountable don't format, wait for the rebuild to finish and then run a filesystem check

Yes, but it will only work if parity is 100% valid, but no harm in trying on a new disk.

Filesystem repair isn't working because disk3 is failing, if you don't have valid parity you can try cloning the disk with ddrescue then repair filesystem, it might work depending on how bad the disk is.

I'm using the same controller and firmware on some of my servers, you're using the latest firmware which is the one recommended.

If you already tried this time to try another HBA.

Does this still happen?

That's fixed on latest release, uprade when done. Disk9 is rebuilding correctly, try refreshing the GUI, or closing the page and re-opening.

HBA problem: Sep 1 10:50:40 TowerTest kernel: mpt2sas_cm0: SAS host is non-operational !!!! Make sure it's well seated and sufficiently cooled, you can also try another PCIe slot if available, then rebuild disk1 and resync parity.

USB enclosures are not recommend for Unraid, one of the many reasons is that they have tendency to drop devices, though yours is showing a constant problem, disks are detect correctly, e.g.: Aug 30 23:55:10 Tower kernel: scsi 7:0:0:0: Direct-Access ST4000DM 004-2CV104 0125 PQ: 0 ANSI: 6 Aug 30 23:55:10 Tower kernel: sd 7:0:0:0: Attached scsi generic sg2 type 0 Aug 30 23:55:10 Tower kernel: sd 7:0:0:0: [sdc] Very big device. Trying to use READ CAPACITY(16). Aug 30 23:55:10 Tower kernel: sd 7:0:0:0: [sdc] 7814037168 512-byte logical blocks: (4.00 TB/3.64 TiB) Aug 30 23:55:10 Tower kernel: sd 7:0:0:0: [sdc] 4096-byte physical blocks Aug 30 23:55:10 Tower kernel: sd 7:0:0:0: [sdc] Write Protect is off Aug 30 23:55:10 Tower kernel: sd 7:0:0:0: [sdc] Mode Sense: 67 00 10 08 Aug 30 23:55:10 Tower kernel: sd 7:0:0:0: [sdc] No Caching mode page found Aug 30 23:55:10 Tower kernel: sd 7:0:0:0: [sdc] Assuming drive cache: write through Then there's this error: Aug 30 23:55:10 Tower kernel: usb 4-6: Device not responding to setup address. Aug 30 23:55:10 Tower kernel: usb 4-6: Device not responding to setup address. Aug 30 23:55:11 Tower kernel: usb 4-6: device not accepting address 4, error -71 Aug 30 23:55:15 Tower kernel: usb usb4-port6: Cannot enable. Maybe the USB cable is bad? Aug 30 23:55:19 Tower kernel: usb usb4-port6: Cannot enable. Maybe the USB cable is bad? Aug 30 23:55:23 Tower kernel: usb usb4-port6: Cannot enable. Maybe the USB cable is bad? Aug 30 23:55:23 Tower kernel: usb 4-6: USB disconnect, device number 4 And all disks drop out and capacity can't be read: Aug 30 23:55:23 Tower kernel: sd 7:0:0:0: [sdc] tag#0 UNKNOWN(0x2003) Result: hostbyte=0x01 driverbyte=0x00 Aug 30 23:55:23 Tower kernel: sd 7:0:0:0: [sdc] tag#0 CDB: opcode=0x88 88 00 00 00 00 00 00 00 00 20 00 00 00 08 00 00 Aug 30 23:55:23 Tower kernel: print_req_error: I/O error, dev sdc, sector 32 Aug 30 23:55:23 Tower kernel: Buffer I/O error on dev sdc, logical block 4, async page read Aug 30 23:55:23 Tower kernel: sd 7:0:0:0: [sdc] Read Capacity(16) failed: Result: hostbyte=0x01 driverbyte=0x00 Aug 30 23:55:23 Tower kernel: sd 7:0:0:0: [sdc] Sense not available. Aug 30 23:55:23 Tower kernel: sd 7:0:0:0: [sdc] Read Capacity(10) failed: Result: hostbyte=0x01 driverbyte=0x00 Aug 30 23:55:23 Tower kernel: sd 7:0:0:0: [sdc] Sense not available. Aug 30 23:55:23 Tower kernel: sd 7:0:0:0: [sdc] 0 512-byte logical blocks: (0 B/0 B) Aug 30 23:55:23 Tower kernel: sd 7:0:0:0: [sdc] 4096-byte physical blocks Aug 30 23:55:23 Tower kernel: sd 7:0:0:0: [sdc] Attached SCSI disk Then the process starts again and keeps repeating, for all disks.

sdc is the 2TB WD unassigned disk, errors appear to be happening when Unraid is trying to spin it down, should be harmless, but you can try disabling spin down for that disk or connecting it to a different controller if possible.

I know it's being looked at, hopefully will be fixed for 6.8

Unraid doesn't keep track of parity checks, if it complained about an unclean shutdown most likely previous shutdown was unclean.

Please post the diagnostics: Tools -> Diagnostics

Assuming parity is valid you can do this: -Tools -> New Config -> -Assign all disks, including new disk2 -Important - After checking the assignments leave the browser on that page, the "Main" page. -Open an SSH session/use the console and type (don't copy/paste directly from the forum, as sometimes it can insert extra characters): mdcmd set invalidslot 2 29 -Back on the GUI and without refreshing the page, just start the array, do not check the "parity is already valid" box (GUI will still show that data on parity disk(s) will be overwritten, this is normal as it doesn't account for the invalid slot command, but they won't be as long as the procedure was correctly done), disk2 will start rebuilding, disk should mount immediately but if it's unmountable don't format, wait for the rebuild to finish and then run a filesystem check

Parity disk is still on the same port, you could have done what I suggested, swapping the disk cables with another one.

It might not be redirecting to the correct IP, and you can re-enable after.