JorgeB

Please post diags.

xfs_repair is aborting due to metadata corruption, you can try upgrading to v6.10-rc1 and running it again since it includes newer xfs-progs, but I suspect there's an underlying hardware issue and trying to repair might not be very successful.

Sep 29 08:41:18 NAS emhttpd: unclean shutdown detected An auto-parity check starts after any unclean shutdown, and it's non correct, so you need to run a correcting check, and figure out what is causing the unclean shutdowns.

Enable user shares: Settings -> Global Share Settings

Can't help much more as I can't duplicate that or ever needed to use those options, look at the man page for gdisk: https://linux.die.net/man/8/gdisk

fdisk /dev/sdX Double check it's the correct device then type d then w to writes changes

Like suspected this is the problem, Unraid standard partition start is sector 64, except for non rotational devices, this partition starts on sector 2048, so it's smaller than it should be, you need to erase the current partition with fdisk then let Unraid repartition the disk, though it should detect the non standard partition and do it automatically.

Yes.

Erase current partition with fdisk and let Unraid recreate it, you'll need to re-sync parity.

That is the problem, parity partition starts on sector 2048, so it's smaller than the other one, normal starting sector for Unraid is sector 64 (except for non rotational devices), so you'd need to wipe parity first and let Unraid repartition it.

Disks have the same number of sectors, but the size being detected by Unraid is different: Likely partition on parity2 starts on sector 2048 instead of the standard Unraid sector 64, can you please post the output of: fdisk -l /dev/sdX replace X with the correct letter for both disks.

Use -L

Please post output of fdisk -l /dev/sdc

It's logged as a disk problem, run an extended SMART test on parity, or a non correcting parity check if one is due.

Check filesystem is going to help here, best bet is using btrfs restore like I mentioned above, I think the instructions in the FAQ are fairly easy to follow even for users not familiar with the CLI, but feel free to ask here if you have any doubts.

No need to backup, you can recreate the docker image not sure it will help but it won't hurt: https://forums.unraid.net/topic/57181-docker-faq/?do=findComment&comment=566089

Did you find out what it was?

Those are usually due to firmware issues, value changed and went back to 0, that should be safe to ignore.

Depends on what you use, I rely on btrfs for data corruption detection and use snapshots together with send/receive to backup all my servers, but I do agree that the typical Unraid user who probably doesn't care or is not going to use these feature should use xfs for the array.

No info there, but not all drives report running tests.

Unfortunately there's nothing relevant logged before the crash, this usually points to a hardware problem.

It's recommended to run memtest for a few hours, up to 24, though a problem that would cause 3 disks to go unmountable should be easily found it it was bad RAM, if there are no apparent RAM issues next step is to check filesystem on the affected disks.

Log is filled with ATA errors for multiple devices similar to these: Sep 28 13:58:22 Tower kernel: ata10: softreset failed (1st FIS failed) Sep 28 13:58:29 Tower kernel: ata10: SATA link up 6.0 Gbps (SStatus 133 SControl 300) Sep 28 13:58:29 Tower kernel: ata10.00: ATA-10: ST12000VN0007-2GS116, ZJV05NBM, SC60, max UDMA/133 Sep 28 13:58:29 Tower kernel: ata10.00: 23437770752 sectors, multi 16: LBA48 NCQ (depth 32), AA Sep 28 13:58:29 Tower kernel: ata10.00: configured for UDMA/133 Sep 28 13:58:29 Tower kernel: scsi 10:0:0:0: Direct-Access ATA ST12000VN0007-2G SC60 PQ: 0 ANSI: 5 Sep 28 13:58:29 Tower kernel: sd 10:0:0:0: Attached scsi generic sg7 type 0 Sep 28 13:58:29 Tower kernel: sd 10:0:0:0: [sdh] 23437770752 512-byte logical blocks: (12.0 TB/10.9 TiB) Sep 28 13:58:29 Tower kernel: sd 10:0:0:0: [sdh] 4096-byte physical blocks Sep 28 13:58:29 Tower kernel: sd 10:0:0:0: [sdh] Write Protect is off Sep 28 13:58:29 Tower kernel: sd 10:0:0:0: [sdh] Mode Sense: 00 3a 00 00 Sep 28 13:58:29 Tower kernel: sd 10:0:0:0: [sdh] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA Sep 28 13:58:29 Tower kernel: ata10.00: exception Emask 0x10 SAct 0x4000 SErr 0x90202 action 0xe frozen Sep 28 13:58:29 Tower kernel: ata10.00: irq_stat 0x00400000, PHY RDY changed Sep 28 13:58:29 Tower kernel: ata10: SError: { RecovComm Persist PHYRdyChg 10B8B } Sep 28 13:58:29 Tower kernel: ata10.00: failed command: READ FPDMA QUEUED Sep 28 13:58:29 Tower kernel: ata10.00: cmd 60/08:70:00:00:00/00:00:00:00:00/40 tag 14 ncq dma 4096 in Sep 28 13:58:29 Tower kernel: res 40/00:70:00:00:00/00:00:00:00:00/40 Emask 0x10 (ATA bus error) Sep 28 13:58:29 Tower kernel: ata10.00: status: { DRDY } Sep 28 13:58:29 Tower kernel: ata10: hard resetting link Check/replace all cables on the affected disks, including power, power back up and see if the errors went way, or post new diags.

Check filesystem on disk3.

3 disks getting corruption at the same time is not normal and could indicate an underlying hardware problem, I would start by running memtest before attempting any fs repairs.