TRK_VOLUME_NOT_OWNED (0X0DEAD103) Fix: Volume Claimed by Another System

You're running a Windows Server 2019 or 2022 failover cluster. You try to bring a CSV (Cluster Shared Volume) online. Right in the cluster management console, you see TRK_VOLUME_NOT_OWNED with the hex code 0X0DEAD103. Or maybe you're in a Hyper-V or SQL Server cluster and the disk shows as "Online (No Access)". The event log might also list this error in the System log under source "disk" or "ClusDisk".

The trigger: you've moved that disk from one cluster node to another — maybe during a failover test, or after replacing a failed server. The old node still claims ownership in the disk's hidden metadata. The new node sees the volume, but the cluster says "nope, not yours."

Root Cause

Every disk in a Windows cluster has a tiny piece of ownership data written directly to the disk's reserved area. This isn't in the filesystem — it's in the disk's partition table metadata. When the old owner didn't properly release the disk (e.g., a hard power-off, or a forced eviction), that ownership flag stays set. The new node detects it and throws 0X0DEAD103. Think of it like a hotel room key that only works for one guest. The new guest needs the front desk to reset the lock.

Fix: Clear the Old Owner

You've got two solid ways to fix this. Pick the one that matches your comfort level. I prefer PowerShell because it gives you better feedback.

Option A — Diskpart (Quick, GUI-friendly)

1. Open a Command Prompt as Administrator. Right-click Start, select "Command Prompt (Admin)" or "Windows PowerShell (Admin)".
2. Type diskpart and press Enter. You'll see the prompt change to DISKPART>.
3. Type list disk and press Enter. Write down the disk number that matches your problem volume. It'll likely be the one with a "No" under "Dyn" or "Gpt" — but verify by size.
4. Type select disk X (replace X with that number). Press Enter. You should see "Disk X is now the selected disk."
5. Type uniqueid disk and press Enter. It shows the current disk signature. Write it down somewhere. You'll need it.
6. Now type clean and press Enter. This wipes the partition table. All data on the volume will appear gone. Wait — don't panic. You're going to undo it next.
7. Type convert mbr (or convert gpt if it was GPT) and press Enter. This rebuilds the partition table but with a brand-new signature.
8. Type exit to close diskpart.
9. Go back to the Failover Cluster Manager. Right-click the disk and choose "Bring Online". The cluster will see the new disk signature and accept it.

Expected outcome after step 7: The disk will show as "Online" in Disk Management, but with no drive letter — just empty space. That's normal. The data is still there on the underlying sectors. The partition table was just rebuilt.

Option B — PowerShell (Safer, preserves disk signature)

1. Open PowerShell as Administrator.
2. Type Get-Disk | Select-Object Number, FriendlyName, Size, OperationalStatus and press Enter. Find your problem disk. Note its number.
3. Type Clear-Disk -Number X -RemoveData -RemoveOEM (replace X). Press Enter. Confirm when prompted. This clears partition information but leaves the disk signature intact.
4. Now type Initialize-Disk -Number X -PartitionStyle MBR (or GPT). Press Enter.
5. Type New-Partition -DiskNumber X -UseMaximumSize -AssignDriveLetter and press Enter. This creates a new partition. The volume will appear in Explorer with a drive letter.
6. Open Failover Cluster Manager and bring the disk online.

What to expect after step 5: The volume will show as "Healthy (Primary Partition)" in Disk Management. Don't worry about the old drive letter — you can reassign it later if needed.

Still Failing? Check These

If the error comes back after you've done the fix, look at these:

• Disk signature collision: Two disks in the cluster might have the same signature. Run Get-Disk | Format-Table Number, UniqueId, FriendlyName in PowerShell. If you see duplicates, one disk needs a new signature. Use Set-Disk -Number X -Signature 0x12345678 (pick any hex value not in use).
• Inconsistent cluster quorum: If the cluster itself thinks the disk is owned by a dead node, you might need to evict that node completely. Run Remove-ClusterNode -Name DeadNodeName in PowerShell on the surviving node.
• Third-party multipath drivers: Some storage arrays (like Dell MD or HP 3PAR) write their own ownership tags. Check your array management interface for "host mapping" or "LUN ownership". The array might be telling the wrong server "yes, you own this".
• BitLocker or encryption: If the volume was encrypted, the new node can't read the metadata. Suspend BitLocker, run the fix, then re-enable.

One last thing — never leave a cluster disk with its drive letter mapped on multiple nodes. That's asking for corruption. After the fix, make sure only the cluster-managed mount points exist. Good luck.