Cluster resource 0X000013CF: NODE_CANT_HOST_RESOURCE fix

Yeah, that error is annoying. You've got a cluster resource sitting there with a status of "Offline" and no matter how many times you click "Bring Online", it throws 0x000013CF — ERROR_NODE_CANT_HOST_RESOURCE. The resource is healthy, the disks are fine, but Windows says the node can't host it. Here's what's actually happening and how to fix it.

Immediate fix: reset the quorum witness

What's happening here is that the cluster's quorum configuration thinks the witness is required for the resource to come online, but the witness is either missing, misconfigured, or unreachable from the current node. The cluster resource can't start because the quorum isn't satisfied — not because the resource itself is broken. The fix is to force the cluster to re-evaluate the quorum configuration. Run this PowerShell command from a node that has quorum:

Stop-Service -Name ClusSvc -Force
Start-Service -Name ClusSvc
Get-ClusterQuorum
Set-ClusterQuorum -NodeWeight 1 -NodeMajority

That's three steps. Step 1 stops the cluster service on all nodes. Step 2 starts it back (you'll lose quorum briefly — don't do this during active production unless you've got a failover window). Step 3 resets the quorum configuration to a simple Node Majority. If you're using a File Share Witness or Cloud Witness, skip step 3 and instead run:

Set-ClusterQuorum -FileShareWitness \\fileserver\share

The reason step 3 works is that it clears any stale witness metadata that's stuck in the cluster database. When a witness becomes unreachable (e.g. a file share got moved, or the Azure blob changed, or the disk witness was removed), the cluster marks all resources as "pending" on the node that used to own it. The fix forces a fresh quorum negotiation. After this, your resource should be online. If it's not, add the witness back explicitly with the correct path.

Real-world trigger

I've seen this most often after a storage administrator accidentally moves a file share witness to a different server without updating the cluster. The cluster still has the old UNC path, the witness isn't there, and every time a node tries to bring a resource online, it checks quorum, fails, and spits out 0x000013CF. Another common trigger: a cross-site cluster where one site loses WAN connectivity. The node in the surviving site can't reach the witness, so the cluster thinks it's lost quorum.

Less common variations of the same root cause

Sometimes the fix above doesn't work because the issue isn't the witness path — it's the node weight. Each node in a cluster has a weight (0 or 1) that determines its vote in quorum. If all nodes have weight 0, the cluster can't form quorum even if the witness is fine. Check node weights with:

Get-ClusterNode | Select-Object Name, NodeWeight

If any node shows 0, set it back to 1:

Get-ClusterNode | Where-Object {$_.NodeWeight -eq 0} | Set-ClusterNode -NodeWeight 1

There's also a corner case in Windows Server 2012 R2 where the cluster validation reports a mismatch between the cluster database and the witness location. This shows as event ID 1069 in the cluster log, but the error code is still 0x000013CF. The fix there is to run a validation test on the witness:

Test-Cluster -Include "Storage", "System Configuration" -ReportName "C:\Temp\cluster_test"

If the validation fails on the witness, delete and recreate the witness from scratch. Don't just change the path — delete the witness resource, create a new one, and configure it fresh.

One more variation: if you're using a Cloud Witness and the Azure subscription key expired or the storage account was deleted, the cluster will also throw this error. The fix is to remove the Cloud Witness and add it again with new credentials. On Server 2016 and newer, you can't just update the key — you have to remove and re-add. Annoying, but that's how it is.

Prevention

Three things to do so you don't see this again:

• Document your witness path and check it quarterly. Put the witness share or disk in a place that's never touched by storage admins without a change ticket. If you're using a file share witness, set up a scheduled task that pings the share and logs results.
• Use a separate witness for each cluster. I've seen teams share a single file share witness across multiple clusters — when they move the share, every cluster breaks. Don't do that.
• Test quorum behavior during disaster recovery drills. Simulate a site failure and confirm the surviving nodes can still bring resources online. If they can't, you'll catch the misconfiguration before it's a real outage.

That's it. The fix is almost always the quorum witness path or node weight. Skip the long validation processes — start with the one-liner above. It works 90% of the time.