Cluster quorum loss detected

Storage Cluster Quorum Loss: Real Fixes That Work

Your cluster lost quorum — the shared vote that keeps it running. Here's the fix for the three most common causes, from a real IT guy.

1. Quorum Disk Failed or Disconnected

This is the one I see most often. The quorum disk — usually a small LUN or a witness share — goes offline. Maybe a SAN path lost, maybe the disk itself died. Had a client last month whose entire print queue died because their quorum disk on a Dell MD3200 just stopped responding.

When the quorum disk disappears, the cluster loses its tiebreaker. Nodes can't agree on who's in charge. You'll see event ID 1177 or 1135 in the System log.

Check Disk Status

Open Failover Cluster Manager. Look under Storage -> Disks. If the quorum disk shows as "Failed" or "Offline", you found the problem.

Fix Steps

  1. Open PowerShell as admin on one node.
  2. Run: Get-ClusterQuorum — this tells you what type of quorum you're using (disk, witness, or node majority).
  3. If it's a disk, check if the drive letter or path is accessible on any node. Try Get-Disk to see if the OS sees it.
  4. If the disk is offline in Disk Management, right-click and bring it online. But if it's corrupted, you'll need to replace it.
  5. To use a different quorum disk: go to Failover Cluster Manager, right-click the cluster name, choose More Actions -> Configure Cluster Quorum Settings. Pick "Select quorum witness" and point to a new disk or file share.

Pro tip: Always keep a spare quorum disk on a separate SAN. Costs nothing to provision, saves your weekend.


2. Network Partition Between Nodes

This one's trickier. The disk is fine, but the nodes can't talk to each other over the heartbeat network. Maybe someone unplugged the wrong cable, or a switch rebooted and STP is still converging. I've seen this after a cleaning crew kicked a cable loose.

When the heartbeat network goes down, each node thinks the other is dead. They both try to take ownership of the cluster. Without quorum, neither can — and the cluster stops.

How to Spot It

Run Get-ClusterNetwork on each node. Look for the "Cluster" network that handles heartbeat. If it shows as "Unknown" or "Down", that's the issue. Also check Test-Cluster for network errors.

Fix Steps

  1. Check physical cables. Reseat them on both ends.
  2. Check switch ports. Make sure they're in the same VLAN and not blocked by STP. Use ping -t from one node's heartbeat IP to the other.
  3. If the network is actually up but the cluster lost it, restart the Cluster service on each node. Do this one at a time: Stop-Service ClusSvc, then Start-Service ClusSvc.
  4. If restarting doesn't help, you may need to add a second heartbeat network. Go to Failover Cluster Manager, Networks, right-click a suitable unused network, and enable it for cluster use.

Real scenario: Had a small biz with two nodes connected via a cheap Netgear switch. A power flicker rebooted the switch, but the nodes had UPS. Switch took 2 minutes to start STP. Cluster lost quorum in 30 seconds. Solution: enable PortFast on all switch ports used for heartbeat. Never happened again.


3. Cluster Node Crashed or Powered Down

Sometimes a node just dies. Power supply fails, motherboard goes, someone accidentally shuts it down. In a two-node cluster without a witness, if one node goes offline, the other loses quorum by default.

Windows Server 2012 R2 and later handle this slightly better — they give surviving nodes a chance to hold quorum if the witness is available. But without a witness, it's game over.

Quick Check

Run Get-ClusterNode to see status. If one node is "Down" and the other shows "Up" but the cluster is stopped, you lost quorum.

Fix Steps

  1. Fix the dead node first. Replace hardware, boot it up, make sure it joins the cluster cleanly.
  2. If the dead node is gone for good (like a motherboard failure), you need to force quorum on the surviving node. This is dangerous — do this right.
  3. On the surviving node, open PowerShell as admin. Run: Start-ClusterNode -ForceQuorum. This starts the cluster even without the other node.
  4. Once the cluster is running, remove the dead node permanently: Remove-ClusterNode -Name DeadNodeName.
  5. Then reconfigure quorum to use a witness (a file share or small disk) so a single node failure doesn't kill the cluster again.
Warning: Force quorum is a last resort. If you bring it up wrong, you can corrupt the cluster database. Only do this if you're sure the dead node won't come back.

My opinion: Every two-node cluster should have a file share witness. It's cheap, easy, and prevents this exact scenario. I tell every client: "One node dies, you still run. No witness, you're down."


Quick-Reference Summary Table

Cause Diagnosis Fix
Quorum disk failed Disk shows Failed/Offline in Cluster Manager, event 1177 Replace disk or reconfigure quorum with new witness
Network partition Heartbeat network down, ping fails, event 1135 Check cables, switch config, restart Cluster service
Node crashed One node Down, no cluster, no quorum Fix node or force quorum on survivor, add witness

If you hit this, don't panic. Check the disk first — that's the most common. Network next. Node crash last. And for crying out loud, add a witness. Your future self will thank you.

Related Errors in Hardware – Hard Drives
0X800401C5 Fix 0x800401C5: IStorage missing standard stream on NTFS drives 0X8011081B 0x8011081B: Legacy COM+ components blocked in nonbase partition 0XC00A0024 Fix STATUS_CTX_NOT_CONSOLE (0xC00A0024) on Windows 0X000003EE Fix ERROR_FILE_INVALID (0X000003EE) When File Volume Changes

Was this solution helpful?

EP
Erropedia Team
Tech Support Editors
The Erropedia editorial team researches and documents real-world tech errors from across Windows, Linux, macOS, networking, databases, cloud platforms, and more. Every solution is reviewed for accuracy and updated as software and systems evolve.