TCMapes

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.

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 ProcessUnraid 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. 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. 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. 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: 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 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. 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.

@ich777 - Okay thanks for the information.

Also as soon as i remove the password portion i can use the console open publicip:7778 to connect to it. The in game "Join Multiplayer" lists my server but that also fails to connect. Only the console open command works.

@ich777 - I have figured it out but the container is not honoring the Password= part of my game.ini file. It looks like the docker is just not parsing it during boot. Attempt #1 to fetch config (only-if-cached) from https://api.steampowered.com/ISteamApps/GetSDRConfig/v1?appid=1857950) [2025.12.10-17.22.33:208][ 0]LogVein: Superadmins set: [2025.12.10-17.22.33:208][ 0]LogVein: - [2025.12.10-17.22.33:208][ 0]LogVein: Admins set: [2025.12.10-17.22.33:208][ 0]LogVein: - [2025.12.10-17.22.33:208][ 0]LogHttpServerModule: Starting all listeners... There should be a line LogVein : Password=test132 during startup. Here is my Game.ini ;METADATA=(Diff=true, UseCommands=true) [/Script/Vein.VeinGameSession] ServerName=MapesVein SuperAdminSteamIDs= AdminSteamIDs= Password=test123 HTTPPort=8080 [/Script/Vein.ServerSettings] GS_HungerMultiplier=0.5 GS_ThirstMultiplier=0.5 GS_MaxThirdPersonDistance=600 GS_ShowScoreboardBadges=1 [OnlineSubsystemSteam] GameServerQueryPort=27018 bVACEnabled=0 [URL] Port=7778

Where can I find the server name and password configuration for the Vein dedicated docker?

When i enable validation flag to true the docker gets the latest version of Valheim but it resets my server data. What is wrong?

I am having issues with Windows 11 VM and Server 2025 VM with this month KB5060842 causing the system BSOD with unsupported CPU. Boots fine with no pinned CPU's but once I PIN a CPU or select more than 1 unpinned CPU it BSOD. Has anyone found a fix for this or experienced this with their windows VM

Seems to only happen when TDARR is transcoding files

I don't disagree but this system has been stable for years. Not sure what component is failing or what is going on. Syslog is not evening sending information about hardware issues.

Need some assistance with diagnostics on why my system is randomly rebooting. Any feedback would be greatly appreciated. foundation-diagnostics-20250416-0813.zip syslog

Sorry if this has already been answered. How can I run BepInExPack_Valheim mods on the ich777 valheim composed docker? Anyone have instructions on how to add mods manually?

Sounds good then I will abandon and start moving data with unbalanced so i can reformat my drives as xfs and my cache pools as btrfs

So you are suggesting I go back to xfs for the array and not bother with ZFS?

That is not my understanding of how Unraid Array behaves with ZFS. You do get some benefits from the provide article, "https://unraid.net/blog/zfs-guide" I am not running ZFS in separate pools just the drives are formatted as ZFS with no ZFS Pools. I am just not sure if I need the Archive RAM feature of ZFS in the Unraid Array setup of ZFS. I am actually hoping the newer version of Unraid will allow more of the native ZFS pool features. Thought was doing this way would future proof me for where Unraid will ultimately go with Opting all features of ZFS in the native Unraid algo.