I recently went through a brutal experience while attempting to shrink my Unraid array by removing a single drive. Everything appeared straightforward—I preserved disk assignments, pulled out the unneeded drive, and let the array handle the rest.

Instead, I hit a nightmare scenario: several remaining data disks came up as "Unmountable" / "No Filesystem" / "Unknown Disk Format", xfs_repair failed with "bad primary superblock - bad magic number; unable to verify secondary superblock," and a full parity sync didn't fix it. Ultimately, I was forced into a corner where I had to reformat the affected disks.

After digging deep into system logs (syslog-previous), diagnostics, and XFS metadata mechanics, I wanted to share what actually happens under the hood during this process so others can avoid it.

The Core Flaw in Unraid's Shrink Process

Unraid treats a "New Config" as a casual tool for rearranging or shrinking hardware, but parity is strictly bound to your total disk count and slot geometry.

1. Slot Index & Parity Mismatch: When you remove a data disk and use a New Config (even with "Retain current assignments"), the parity calculation is instantly invalidated. If the array re-imports or evaluates the remaining disks before parity and slot geometry are fully realigned, the kernel mount command can fail to read the primary XFS superblocks.

2. The "Unmountable" Trap: Once Unraid flags a drive as unmountable due to a read failure or metadata desync during that mass-mount sequence, standard repair tools like xfs_repair frequently fail if the primary magic number (XFSB) is missing and secondary superblocks are out of sync.

3. The Dead-End: When automated repair and parity sync fail to bring the drive back, the WebGUI offers no alternative recovery path—leaving you staring at a format button to rescue the physical slot.

How to Protect Yourself (The Pre-Flight Checklist)

If you ever need to shrink your array or run a New Config involving active XFS data disks, never rely on Unraid's default assumptions. Do this instead:

1. Take Native XFS Metadata Backups First (xfs_metadump): Before touching a single setting, drop into the terminal and back up the filesystem metadata for your disks. This saves the superblocks, inode btrees, and free space maps without needing to copy actual file data:

   Bash

   xfs_metadump /dev/sdXp1 /boot/config/metadata_backups/diskX.metadump
   

   If a superblock ever gets corrupted or wiped out by a bad mount sequence, you can restore it using:

   Bash

   xfs_mdrestore /boot/config/metadata_backups/diskX.metadump /dev/sdXp1
   

2. Empty the Target Disk Completely: Ensure the disk you are removing has 0 bytes of used space by moving all data off it via user shares or Midnight Commander before stopping the array.

3. Treat a Shrink as a Destructive Operation: Do not assume "Retain current assignments" will gracefully handle a shrinking data pool. Parity must be invalidated and cleanly rebuilt from scratch to match the new, reduced layout.

Unraid is an incredible platform for hardware failure protection, but its handling of logical array shrinks and superblock recovery leaves massive safety gaps. Hopefully, keeping a metadata backup (xfs_metadump) handy saves someone else from being forced into a destructive format.

Edited 15 hours ago15 hr by TCMapes

Something is missing here, a new config by itself will not touch any of the data disks.

You are completely right, and I appreciate the technical clarification—a New Config by itself just resets super.dat and doesn't inherently write to or wipe data disks.

The core issue I ran into during the shrink wasn't that the New Config maliciously touched the drives, but rather that the combination of removing a disk, altering the array geometry, and re-importing under a New Config put the remaining drives into a state where the kernel completely failed to read the primary superblocks ("bad primary superblock - bad magic number").

Once they hit that unmountable wall during the mount sequence, standard repair (xfs_repair) couldn't recover them due to secondary superblock sync issues, leaving the slot completely dead until it was formatted.

So the takeaway isn't that New Config deletes data, but rather that shrinking an array via New Config can easily trigger an unmountable superblock state if geometry/parity don't align perfectly—and once you're in that state, recovery options are painfully slim. That's why taking an xfs_metadump beforehand is so critical.