Hi, maybe someone can already help me with this info, I can upload a proper log / diagnostic tomorrow.

Apr 12 22:34:40 Tower kernel: ata5.00: status: { DRDY }

Apr 12 22:34:40 Tower kernel: ata5.00: failed command: READ FPDMA QUEUED

Apr 12 22:34:40 Tower kernel: ata5.00: cmd 60/40:c0:e0:04:5d/00:00:00:04:00/40 tag 24 ncq dma 32768 in

Apr 12 22:34:40 Tower kernel: res 40/00:01:01:4f:c2/00:00:00:00:00/00 Emask 0x4 (timeout)

...
Apr 12 22:37:56 Tower kernel: ata5.00: sense data available but port frozen

Apr 12 22:37:56 Tower kernel: ata5.00: exception Emask 0x10 SAct 0x80fc0007 SErr 0x400101 action 0x6 frozen

Apr 12 22:37:56 Tower kernel: ata5.00: irq_stat 0x08000000, interface fatal error

Apr 12 22:37:56 Tower kernel: ata5: SError: { RecovData UnrecovData Handshk }

Apr 12 22:37:56 Tower kernel: ata5.00: failed command: WRITE FPDMA QUEUED

Apr 12 22:37:56 Tower kernel: ata5.00: cmd 61/08:00:28:26:0a/00:00:00:03:00/40 tag 0 ncq dma 4096 out

Apr 12 22:37:56 Tower kernel: res 43/84:01:00:00:00/00:00:00:00:00/00 Emask 0x10 (ATA bus error)

Apr 12 22:37:56 Tower kernel: ata5.00: status: { DRDY SENSE ERR }

Apr 12 22:37:56 Tower kernel: ata5.00: error: { ICRC ABRT }

Apr 12 22:37:56 Tower kernel: ata5.00: failed command: WRITE FPDMA QUEUED

Apr 12 22:37:56 Tower kernel: ata5.00: cmd 61/08:08:30:26:0a/00:00:00:03:00/40 tag 1 ncq dma 4096 out

Apr 12 22:37:56 Tower kernel: res 43/84:01:00:00:00/00:00:00:00:00/00 Emask 0x10 (ATA bus error)

Apr 12 22:37:56 Tower kernel: ata5.00: status: { DRDY SENSE ERR }

Apr 12 22:37:56 Tower kernel: ata5.00: error: { ICRC ABRT }

Apr 12 22:37:56 Tower kernel: ata5.00: failed command: READ FPDMA QUEUED

SMART data showed:
Reallocated Sectors = 0

Pending Sectors = 0

Uncorrectable = 0

I guessed I hit the SATA cable when I replaced a SSD, so I switched out the cable and also switched the SATA Port, just in case.

Did a test read with dd if=/dev/sde of=/dev/null bs=100M status=progress and checked the log:

I guess it wasn't just hit to the cable...?

I'm still on warranty and checked RMA with Toshiba, but before RMAing and uploading 14TB of data to a friends unRAID, I would like to know if my HDD is dying or my SATA ports are just F-ed, since it's an old Z68 Sandy Bride board.

Thanks.

Looks like connection problems, data or power, possibly controller but that would usually affect multiple disks.

Attach Diagnostics ZIP to your NEXT post in this thread.

55 minutes ago, GerryGER said:

ICRC ABRT

This typically means a bad SATA cable.

tower-diagnostics-20260414-1826.zip

Edit: Wtf is it with the unRAID Forum deleting whole messages, when attaching the diagnostics... anyway, I'm not typing all of it again.
TL;DR
FYI: OG error happened on Mainboard SATA Port -> new cable and attached to JMB585 -> error occurred again -> switched out to a new cable again and attached back to Mainboard Port since I'm still waiting on my LSI 9207-8i.

Edited April 14Apr 14 by GerryGER

SMART for disk6 looks fine.

Emulated disk6 is mounted and very full, as are all of your array drives. You really should keep some free space on each in case you ever need to check filesystem.

Should be OK to rebuild on top if you fix the connection problem.

57 minutes ago, trurl said:

Should be OK to rebuild on top if you fix the connection problem.

Yeah and that's the problem... I already changed cables twice and used different SATA Ports. The result is still this:

I mean I could wait until the HBA arrives and try with that, but I would prefer to try the HBA with a working unRAID... anyway, I ordered brand new SATA cables, just to be sure. I can check those tomorrow.

Be sure to check power to the drive also. Do you have any power splitters?

18 minutes ago, trurl said:

Be sure to check power to the drive also. Do you have any power splitters?

No splitters, the PSU is also rather new (max. 2 years or so).

Because of your previous comment I regained my hope ;) and tried once more. I connected the HDD to a different Port on the JMB and reseated the SATA Power, lets see...

Edit: Yeah, that didn't work out. I will switch to a different SATA Power port, just in case...

Edit 2: I'm having a virtual stroke right now, I went back and checked my screenshot with all my drives and... well, realized that BOTH MY TOSHIBAS END ON THE SERIAL F94G... when searching the HDD, I only checked those last 4 digits and was working on the wrong drive the whole time! Get the Cat5 o’ nine tails and give me a good whipping and do it again for me still not having labeled them! And do it a third time, for me forgetting that I put the drives in Top Down order from Parity to last Disk inside the case...

So I changed the correct SATA cable now and also switched the SATA Power port, just in case. First 150GB are looking fine.

Now at 600GB read and its still looking clean.
What would the recommended best practice approach be? Rebuilding or trusting the drive? I'm pretty (like 99,x%) sure I haven't written anything to the disk since the error. Moved from it? Not 100% sure, but since the disk is basically full, I doubt it or is the stat on that not correctly displayed, since it was emulated?

Edited April 14Apr 14 by GerryGER

If the emulated disk is mounting and contents look correct, we generally recommend rebuilding.

18 hours ago, GerryGER said:

Rebuilding or trusting the drive?

The drive was disabled when a write to it failed. Unraid does not use the disk after that. That failed write, and any subsequent writes to the disabled disk, are still in the array because parity is updated, and that data is emulated from the parity calculation. Rebuild will recover those writes.

If you "trust" the disk instead the array is still out-of-sync since parity and the "trusted" disk don't agree. So then you have to rebuild parity, but you would have lost those emulated writes.

In some extreme cases, it might make sense to trust the disk, rebuild parity, and accept the losses. But if you can rebuild, that is the whole point of parity, to recover the data.

18 hours ago, GerryGER said:

the disk is basically full

All your disks are mostly full, so any write to user shares has to choose one of those mostly full disks. If you have Minimum Free for the share set, that will help it choose an appropriate mostly full disk.