Fix ERROR_QUORUM_DISK_NOT_FOUND (0X000013DE) on Windows Failover Cluster

Quick Answer

If the quorum disk still exists but the cluster service won't start, run cluster.exe /quorum /restore from the Windows Recovery Console or a command prompt. That bypasses the missing disk check and lets the cluster load.

Why This Happens

This error means the Cluster service scanned for the quorum disk's physical disk resource and came up empty. I've seen this most often after a SAN reconfiguration, a disk failover to a different LUN, or after restoring the cluster database from backup. The disk itself might still be there, but its signature changed — or the cluster database holds a stale reference. Windows Server 2012 R2, 2016, 2019, and 2022 all behave the same here. The culprit is almost always a disk signature mismatch.

Step-by-Step Fix

1. Check if the disk is visible to the node. Open Disk Management (diskmgmt.msc). If the quorum disk shows as "Unknown" or "Offline", right-click it and bring it online. If it's missing entirely, rescan disks from the Action menu.
2. Verify disk signature matches cluster database. Run diskpart, then list disk. Note the disk number for your quorum disk. Then run select disk X and detail disk. Look for the Disk ID. Compare it to what the cluster expects: open a command prompt as admin and run cluster.exe /quorum. It shows the quorum resource path and disk signature. If they don't match, you'll need to either fix the disk signature or restore the cluster quorum.
3. If the disk is offline or missing, force it online. In Disk Management, right-click the disk and select "Online". If it's a shared disk, ensure the SAN presents it to this node exclusively — split-brain setups cause this error too.
4. Restore the quorum from backup. If the disk signature changed and you can't revert it, restore the quorum from a backup file. First, stop the Cluster service on all nodes. On the node you intend to be the owner, run:

   cluster.exe /quorum /restore

   This loads the cluster database without requiring the original quorum disk. Then start the Cluster service and run the Validate a Configuration wizard.
5. Manually update the quorum disk path. If you can't restore from backup and you know the new disk signature, you can force it. But don't bother — it's easier to evict the disk from cluster storage and add it again. That rebuilds the quorum.

Alternative Fix: Evict and Re-add the Disk

If restoring from backup didn't work or you don't have a backup (stupid, I know, but happens), evict the problematic disk from cluster storage entirely.

1. Open Failover Cluster Manager.
2. Go to Storage → Disks.
3. Right-click the quorum disk and select Remove. Confirm.
4. In Disk Management, bring the disk online and assign it a drive letter if needed.
5. Back in Failover Cluster Manager, right-click Storage and choose Add Disk. Select the disk.
6. Configure the quorum: right-click the cluster name → More Actions → Configure Cluster Quorum Settings. Choose Add or change the quorum witness and pick this disk.

This rebuilds the quorum from scratch. You lose any stored cluster configuration details that were tied to the old disk — usually none, but check your application's cluster resources.

Prevention Tip

The one thing that stops this error cold: always back up the cluster quorum before any SAN change. Run this on a regular basis and definitely before disk migrations:

cluster.exe /quorum /backup C:\ClusterBackup\

Also, make sure all nodes see the same disk signature. If a SAN admin rearranges LUNs and the disk gets a new signature, the cluster won't start. Set a strict change management policy that requires a quorum backup before any storage reconfiguration.

And for the love of god, don't remove the quorum disk while the cluster is running. That's the fastest way to trigger this error on a live system. Done that myself once at 2 AM. Never again.