Team,

Hope the weekend went well, I am having two issues with my Unraid v7.2.3 server.

1) I've been having issues with running my Unraid NAS server in headless mode, causing me to have to shutdown, add the graphics card back in and keep editing BIOS settings to see the URL will load. While doing this I noticed Disk 2 and Disk 3 showing up as unmoutable, wrong or no file system. I stopped the array and unassigned both disks and tried the mount button, but it came back with failed, check syslogs. Next I added them both back and started the array in maintenance mode, tried Check Filesystem Status for both disks. xfx_repair status did not get past, attempting to find secondary superblock. I checked PHP Settings logs and they are empty.

Before I click format both drives I wanted to reach out and see if there is anything I missed or another step to take. My parity drive and disk1 are both valid and working properly, no data has been lost. I also shut down the system from web URL and reset SATA cables at the motherboard but that did not resolve my issue.

2) I cant seem to edit Parity/array around. I want to create Parity1 & Parity2 with disk1 and disk2. When I unassign and create the new setup, I get a configuration not valid. I also cant edit the slot tab from 5 to 4. Ideas?

Edited March 16Mar 16 by Coban64

Attach Diagnostics ZIP to your NEXT post in this thread.

Thanks for helping! Tower diagnostics attached.

tower-diagnostics-20260316-1325.zip

16 hours ago, Coban64 said:

I want to create Parity1 & Parity2 with disk1 and disk2.

I question whether dual parity is justified with so few disks, and it probably wouldn't have helped with your current problem.

16 hours ago, Coban64 said:

Before I click format both drives I wanted to reach out and see if there is anything I missed or another step to take. My parity drive and disk1 are both valid and working properly, no data has been lost.

Do you mean you don't care about anything that was stored on disks 2, 3?

Just now, trurl said:

it probably wouldn't have helped with your current problem

probably is probably too soft. Single or dual parity can't help with unmountable.

Creating a two parity is just something I wanted to do in case parity1 drive failed. It was not something I thought was not going to resolve my disk2 and 3 unmout problem. Since parity 1 and disk1 drives are functional is my only option to check off format button and format disk2 and 3 again? Or can I resolve this issue another way? Anything telling in diagnostics?

Thanks,

Let it try longer to find secondary superblock

I will let it run for 24hs and report afterwards.

Thanks,

Its been 17hs and its still looking for secondary superblock. Zip diagnostics attached.

tower-diagnostics-20260317-1359.zip

18 hours ago, Coban64 said:

Creating a two parity is just something I wanted to do in case parity1 drive failed

Parity is arguably the least important disk in the array, since it contains none of your data. If it fails, replace and rebuild just like any other array disk.

6 minutes ago, Coban64 said:

still looking for secondary superblock

Start the array in normal (not maintenance) mode and post new diagnostics

You can cancel that; if it hasn't found a backup superblock after 1 or 2 hours, it won't find one.

Looking at the syslog, something is missing here from your description, I see that the disks were already unmountable before that, but just what you did by the description would not explain Unraid repartitioning them:

Mar 15 21:34:09 Tower emhttpd: writing GPT on device (sdd) with partition 1 offset 64

Mar 15 21:34:09 Tower emhttpd: shcmd (303): sgdisk -Z /dev/sdd

Mar 15 21:34:10 Tower root: Warning: The kernel is still using the old partition table.

Mar 15 21:34:10 Tower root: The new table will be used at the next reboot or after you

Mar 15 21:34:10 Tower root: run partprobe(8) or kpartx(8)

Mar 15 21:34:10 Tower root: GPT data structures destroyed! You may now partition the disk using fdisk or

Mar 15 21:34:10 Tower root: other utilities.

Mar 15 21:34:10 Tower emhttpd: shcmd (304): sgdisk -o -a 8 -n 1:32K:0 /dev/sdd

Mar 15 21:34:11 Tower root: Creating new GPT entries in memory.

Mar 15 21:34:11 Tower root: Warning: The kernel is still using the old partition table.

Mar 15 21:34:11 Tower root: The new table will be used at the next reboot or after you

Mar 15 21:34:11 Tower root: run partprobe(8) or kpartx(8)

Mar 15 21:34:11 Tower root: The operation has completed successfully.

Mar 15 21:34:11 Tower emhttpd: shcmd (305): udevadm settle

Mar 15 21:34:13 Tower emhttpd: writing GPT on device (sdf) with partition 1 offset 64

Mar 15 21:34:13 Tower emhttpd: shcmd (307): sgdisk -Z /dev/sdf

Mar 15 21:34:14 Tower root: Warning: The kernel is still using the old partition table.

Mar 15 21:34:14 Tower root: The new table will be used at the next reboot or after you

Mar 15 21:34:14 Tower root: run partprobe(8) or kpartx(8)

Mar 15 21:34:14 Tower root: GPT data structures destroyed! You may now partition the disk using fdisk or

Mar 15 21:34:14 Tower root: other utilities.

Mar 15 21:34:14 Tower emhttpd: shcmd (308): sgdisk -o -a 8 -n 1:32K:0 /dev/sdf

Mar 15 21:34:15 Tower root: Creating new GPT entries in memory.

Mar 15 21:34:15 Tower root: Warning: The kernel is still using the old partition table.

Mar 15 21:34:15 Tower root: The new table will be used at the next reboot or after you

Your only option now may be using a file recovery app like UFS Explorer, but let's see if there's a second signature, with the array stopped type.

dd if=/dev/sdX bs=16M status=progress 2>/dev/null | hexdump -C | grep 'XFSB'

Replace X with the identifier from one of those disks, then let it run for 5 minutes and post the output

I ran the command for both disks for about 10min with nothing returned.

That means the disks don't have the correct XFS superblock; the best option may be UFS Explorer or something similar.

Understood, since disk1 is working and I can access my data, can I use the Format box to fix disk2 and 3?

As long as you don't mind losing the data that was there, you can.

If you have a sec, could you explain parity disk to me? I was under the impression that it was the most important drive. Originally I had all of my data on a 8T drive. I added three, 12T drives and created a 1 parity 12T, with three disks, 8T, 12T & 12T Unraid server. So is all of my data spread across the four drives or only the 8T? Is the 8T the most important drive here?

Parity contains no data as such. Instead it has the information needed to recreate a failed drive by using itself in combination with all the other drives. There is a description of how parity works here in the Unraid online focumdntation.

43 minutes ago, itimpi said:

how parity works here

Expand Software-defined NAS section, then expand How Parity Works section

Formatted and back in business team. Thank you very much.

On 3/17/2026 at 2:09 PM, trurl said:

Parity is arguably the least important disk in the array, since it contains none of your data.

Just to elaborate on this.

If a disk is disabled/missing, each remaining disk serves exactly the same purpose as parity, when emulating or rebuilding that disk. Each disk provides bits that in combination with corresponding bits from all other disks, allows the emulated data to be calculated. Parity is not any more important than the others in this regard.

But, parity has none of your data and the data disks do. You can take any of the data disks individually and read them on any linux. Parity is just a bunch of parity bits that are totally meaningless in the absence of the rest of the array.