I need some help. The backstory is a bit long but I want to explain this as detailed as possible. I also attached the Diagnostic file.

I am in the process of upgrading to a larger USB flash drive so I can upgrade to a new version of Unraid (I've been stuck on 7.0 because my USB drive didn't have enough space). I also had 2 older drives that were throwing errors so I replaced them with 1 larger drive.

I have 2 Parity Drives and 8 HDDs in my array. Disk 6 (8 TB) and Disk 7 (8 TB) were the old drives throwing errors so I replaced it with Disk 8 (16 TB). The new drive is brand new. A few weeks ago I transferred all the data from Disk 6 and Disk 7 to Disk 8 uneventfully.

On 8/2, I backed up my old USB boot drive and migrated it into a largest USB drive. It all went well and booted up fine. Then out of nowhere, Disk 8 and Disk 12 both were disabled because it was in an error state. Unraid showed that both drives were being emulated. I checked the cables and reattached them and then I unassigned Disk 8 and Disk 12 and reassigned it. During the Parity Rebuild, Disk 8 showed as disabled again and the Parity rebuild stops. I unpause Parity Rebuild and let Disk 12 finish.

Today (8/4), I change the SATA cable for Disk 8 and reboot the server. For some reason, Disk 8 shows up under "Unassigned Disk Devices". THIS IS WHERE I MAY HAVE MESSED UP... I went to New Config and selected ALL of "Preserve current assignments". This is when I see the "All existing data on this device will be OVERWRITTEN when array is Started". Realizing that I messed up I stopped and haven't touched the server since then and the array is off. I believe the data for Disk 8 is still on the Parity drives.

Is there anyway to undo the New Config? I still have my USB Flash Drive Backup from before I changed the USB drive. Can I use that backup to go back to my old Config?

Thank you in advance!

leungunraid-diagnostics-20250804-2129.zip

You can do a new config and force disable disk8, but if I understood correctly, disk8 should already have all the data, or did you copy data to it after it got disabled? If you didn't, it may be easier just to resync parity with it. You can see if it's mounting and contents look correct using the UD plugin.

If it doesn't look good or there's data missing I can post the instructions to try and rebuild it again.

7 hours ago, JorgeB said:

You can do a new config and force disable disk8, but if I understood correctly, disk8 should already have all the data, or did you copy data to it after it got disabled? If you didn't, it may be easier just to resync parity with it. You can see if it's mounting and contents look correct using the UD plugin.

If it doesn't look good or there's data missing I can post the instructions to try and rebuild it again.

Thanks for your response.

Disk 8 began the Parity Rebuild and stopped less than an hour into it. What I worry about is that part of the data was wiped during that time.

I’ll mount it in UD and check the contents later on today. Thanks!

1 hour ago, UnraidRog said:

Disk 8 began the Parity Rebuild and stopped less than an hour into it.

That should be fine, it would not damage the rest of the disk data, assuming it was correct.

I just got chance to try mounting the disk in question (Disk 8). It wouldn't let me. I assume it's because it's part of the array. I see an option to Change Disk Mount Point. Should I do this?

Thanks

Did you unassign the disk first?

I believe so. It's no longer mounted in the array. Please see screenshot below

Thanks!

Try rebooting first.

Just rebooted. I was able to unassign it. The Mount option shows up now but it's greyed out.

Thanks again for your help I appreciate it.

That's the old disk that was being rebuilt on top correct?

Post the output from:

fdisk -l /dev/sdk

and

wipefs /dev/sdk1

Despite the name, this command won't wipe anything as written.

5 minutes ago, JorgeB said:

That's the old disk that was being rebuilt on top correct?

Post the output from:

fdisk -l /dev/sdk

and

wipefs /dev/sdk1

Despite the name, this command won't wipe anything as written.

Correct.

fdisk -l /dev/sdk

Disk /dev/sdk: 16.37 TiB, 18000207937536 bytes, 35156656128 sectors

Disk model: WDC WD181KFGX-68

Units: sectors of 1 * 512 = 512 bytes

Sector size (logical/physical): 512 bytes / 4096 bytes

I/O size (minimum/optimal): 4096 bytes / 4096 bytes

Disklabel type: gpt

Disk identifier: A9D127F7-2277-4910-A9A0-CBD278462CE6

Device Start End Sectors Size Type

/dev/sdk1 64 35156656094 35156656031 16.4T Linux filesystem

wipefs /dev/sdk1

DEVICE OFFSET TYPE UUID LABEL

sdk1 0x0 xfs 26ebcbef-4efe-4132-9ef4-8139a70439db

That looks OK, and there's an xfs signature:

type:

mkdir /x

mount -o ro -t xfs /dev/sdk1 /x

If it fails, post the errors on the syslog.

(So I'm learning myself) What does this command do? Does it mount it in Unassigned Devices?

Thanks!

You're gonna mount the partition of /dev/sdk1 to /x mount point that you have to create and it's going to mount the disk in a read-only state.

Edited August 13, 2025Aug 13 by MowMdown

I tried the step above and got this:

root@LeungUnraid:~# mkdir /x

mkdir: cannot create directory ‘/x’: File exists

root@LeungUnraid:~# mount -o ro -t xfs /dev/sdk1 /x

mount: /x: mount system call failed: Structure needs cleaning.

dmesg(1) may have more information after failed mount system call.

The "dmesg" command got me a long list of messages. Am I doing this wrong?

Thanks again

The last several lines from the "dmesg" command got me this:

[216889.781259] XFS (sdk1): Metadata CRC error detected at xfs_sb_read_verify+0x10c/0x198, xfs_sb block 0x0

[216889.781548] XFS (sdk1): Unmount and run xfs_repair

[216889.781824] XFS (sdk1): First 128 bytes of corrupted metadata buffer:

[216889.782103] 00000000: 58 46 53 42 00 00 10 00 00 00 00 01 05 ef ff f3 XFSB............

[216889.782390] 00000010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................

[216889.782675] 00000020: 26 eb cb ef 4e fe 41 32 9e f4 81 39 a7 04 39 db &...N.A2...9..9.

[216889.782963] 00000030: 00 00 00 00 80 00 00 07 00 00 00 00 00 00 00 80 ................

[216889.783245] 00000040: 00 00 00 00 00 00 00 81 00 00 00 00 00 00 00 82 ................

[216889.783526] 00000050: 00 00 00 01 0f ff ff ff 00 00 00 11 00 00 00 00 ................

[216889.783799] 00000060: 00 07 f6 00 b4 b5 02 00 02 00 00 08 00 00 00 00 ................

[216889.784067] 00000070: 00 00 00 00 00 00 00 00 0c 09 09 03 1c 00 00 05 ................

[216889.784336] XFS (sdk1): SB validate failed with error -74.

Type xfs_repair -v /dev/sdk1 and post the output.

8 hours ago, JorgeB said:

Type xfs_repair -v /dev/sdk1 and post the output.

root@LeungUnraid:~# xfs_repair -v /dev/sdk1

Phase 1 - find and verify superblock...

bad primary superblock - bad CRC in superblock !!!

attempting to find secondary superblock...

.found candidate secondary superblock...

verified secondary superblock...

writing modified primary superblock

- block cache size set to 2946608 entries

sb root inode value 18446744073709551615 (NULLFSINO) inconsistent with calculated value 128

resetting superblock root inode pointer to 128

sb realtime bitmap inode value 18446744073709551615 (NULLFSINO) inconsistent with calculated value 129

resetting superblock realtime bitmap inode pointer to 129

sb realtime summary inode value 18446744073709551615 (NULLFSINO) inconsistent with calculated value 130

resetting superblock realtime summary inode pointer to 130

Phase 2 - using internal log

- zero log...

zero_log: head block 55 tail block 51

ERROR: The filesystem has valuable metadata changes in a log which needs to

be replayed. Mount the filesystem to replay the log, and unmount it before

re-running xfs_repair. If you are unable to mount the filesystem, then use

the -L option to destroy the log and attempt a repair.

Note that destroying the log may cause corruption -- please attempt a mount

of the filesystem before doing this.

Thanks

Now type xfs_repair -vL /dev/sdk1

50 minutes ago, JorgeB said:

Now type xfs_repair -vL /dev/sdk1

Sweet! I was able to mount it and look at the contents. It looks like most if not all of the data is there. I don't remember the exact total size of the files but it looks pretty close to what I had on the drive.

Is there anyway I can mount the Parity drives to compare the data? Thanks!

43 minutes ago, UnraidRog said:

Is there anyway I can mount the Parity drives to compare the data?

Parity drives have no data do are not mountable.

After doing the xfs_repair look to see if there is a lost+found folder on the drive. That is where the repair process puts files/folders (with numeric names) for which it could not find the directory entry to give the correct name. Not having that folder is a good sign that the repair completed successfully without data loss.

17 minutes ago, itimpi said:

Parity drives have no data do are not mountable.

After doing the xfs_repair look to see if there is a lost+found folder on the drive. That is where the repair process puts files/folders (with numeric names) for which it could not find the directory entry to give the correct name. Not having that folder is a good sign that the repair completed successfully without data loss.

Awesome. I don't see a lost&found folder. Things are looking more promising.

Is it safe to mount it back to my Array and let the Parity drives rebuild?

If the array is still as the last screenshot above, with all blue icons after a new config, you can assign that disk as a data drive, then start the array to re-sync parity.

I have no idea what's going on.... I started the Array and the Parity Sync began, but then I noticed that Disk 12 is showing the "Unmountable: unsupported or no file system" error.

Do I need to complete the same procedure and XFS repair for Disk 12 as well?

Thanks

I think I'm good now. I ran the XFS Repair from the GUI. Parity is now Syncing. Thank you all!