16 minutes ago, Bramovitz said:

I feel it might not be as easy with noob like me.

There are users who have been around for years that still don't understand how all this works.

 

Understanding parity is the first step, and without that understanding, it is difficult to understand anything else about how things have to be done.

 

Parity is basically the same concept wherever it is used in computers and communications. Parity is just an extra bit that allows a missing bit to be calculated from all the other bits. It is an extremely simple calculation.

 

https://docs.unraid.net/unraid-os/overview/nas/#parity-protected-array

The parity has been rebuild. I'm now letting my fam check whether the files are all there and dl them where necessary.
When that's done I'll go back in maintenance mode and check filesystem.
Here's the new diagstower-diagnostics-20250315-1528.zip

That looks good, except for lots of this at beginning of syslog

Mar 14 21:54:25 Tower kernel: ata4.00: failed command: READ FPDMA QUEUED
Mar 14 21:54:25 Tower kernel: ata4.00: cmd 60/40:70:00:d8:b2/05:00:07:00:00/40 tag 14 ncq dma 688128 in
Mar 14 21:54:25 Tower kernel:         res 40/00:01:00:00:00/00:00:00:00:00/00 Emask 0x52 (ATA bus error)
Mar 14 21:54:25 Tower kernel: ata4.00: status: { DRDY }
Mar 14 21:54:25 Tower kernel: ata4: hard resetting link
Mar 14 21:54:31 Tower kernel: ata4: link is slow to respond, please be patient (ready=0)
Mar 14 21:54:35 Tower kernel: ata4: found unknown device (class 0)
### [PREVIOUS LINE REPEATED 1 TIMES] ###

ata4 is the 8TB unassigned disk sdd

[4:0:0:0]    disk    ATA      ST8000VN004-2M21 SC60  /dev/sdd   /dev/sg3 
  state=running queue_depth=32 scsi_level=6 type=0 device_blocked=0 timeout=30
  dir: /sys/bus/scsi/devices/4:0:0:0  [/sys/devices/pci0000:00/0000:00:01.2/0000:02:00.1/ata4/host4/target4:0:0/4:0:0:0]

It wasn't involved during parity rebuild so that was fine. SMART for that disk looks OK. You will need to fix its connection if you want to work with it.

I have changed sata cable and port. The same errors as what you posted are no longer there, so that seems like a win.
When trying to mount, it still fails.
I get this error is Disk Log Information:
Mar 15 23:17:38 Tower unassigned.devices: Mount cmd: /sbin/mount -t 'xfs' -o rw,relatime '/dev/sdc1' '/mnt/disks/WKD09JJ5'
Mar 15 23:17:38 Tower kernel: XFS (sdc1): Mounting V5 Filesystem 5bc3aaf7-andmorenumbers
Mar 15 23:17:38 Tower kernel: XFS (sdc1): Failed to read root inode 0x80, error 22
Mar 15 23:17:39 Tower unassigned.devices: Mount of 'sdc1' failed: 'mount: /mnt/disks/WKD09JJ5: wrong fs type, bad option, bad superblock on /dev/sdc1, missing codepage or helper program, or other error.        dmesg(1) may have more information after failed mount system call.'

When starting in maintenance mode and clicking on the Dev 1 drive (the 8tb), there's no option for filesystem check. Is there a way to do that?

tower-diagnostics-20250315-2319.zip

Edited March 15, 20251 yr by Bramovitz

A little further down in that check filesystem documentation:

 

https://docs.unraid.net/unraid-os/manual/storage-management/#xfs-and-reiserfs

 

In your case that would be

xfs_repair -v /dev/sdc1

Post the output

Excuse the late response, I've had a really busy week and I had to let my fam access the files that they needed.
I've added the output which was cut off for some reason. Is this sufficient or do you need more of the output?

imap claims in-use inode.txt

Disk should mount now.

It does! That is wild to me. That means the only difference is either GUI or through console. Is that such a big difference?
Thanks for the help!

 

Did anything end up in lost+found share?

I used the terminal to get into the drive and also through the GUI, but there's no lost+found share

5 hours ago, Bramovitz said:

through console.

Going via the console should give the same results, but it is very easy to get the device name to use wrong.  Going via the GUI removes that potential error

57 minutes ago, Bramovitz said:

but there's no lost+found share

That is good news it means there were no files/folders found for which the repair process could not give them therir correct name.

That's really good news Thanks a lot