Fix ERROR_RESOURCE_NOT_ONLINE 0x0000138C in Cluster

When This Error Shows Up

You're managing a Windows Server Failover Cluster (WSFC) — might be 2016, 2019, or 2022. You try to bring a resource online through Failover Cluster Manager or PowerShell, and boom: the error pops. The resource sits there grayed out, status says “Offline”, and event log gives you 0x0000138C. I see this most often with Cluster Disk resources, Network Name resources, or IP Address resources that refuse to start after a node reboot or a network change.

Root Cause in Plain English

This error means the Resource Hosting Subsystem (RHS) process can't get the resource to respond. The three most common reasons:

Dependency chain failure — something the resource depends on isn't online yet.
Permission issues — the Cluster Service account doesn't have rights to the object (like a disk partition, a file share, or a DNS record).
Resource conflict — static IP conflicts or disk signature collisions.

Don't bother with generic “reboot the node” crap — it rarely fixes the root cause. Dig into the dependency chain and logs instead.

Step-by-Step Fix

Step 1: Check Dependencies

Open Failover Cluster Manager. Find the failed resource. Right-click → Properties → Dependencies tab. Look at what it needs. Every resource in that list must be online. If any dependency is offline, bring it up first.

Real-world example: I had a Network Name resource fail because the IP Address it depended on was set to a subnet that didn't exist after a VLAN change.

Step 2: Check Cluster Logs

Cluster logs tell you exactly why RHS gave up. Run this on the node hosting the resource:

Get-ClusterLog -Node $env:COMPUTERNAME -TimeSpan 5 | Select-String -Pattern "0x0000138C" -Context 2,5

If you prefer the GUI, open Event Viewer → Applications and Services Logs → Microsoft → Windows → FailoverClustering → Operational. Look for events with ID 1069 or 1230 right before the error.

Step 3: Verify Permissions on the Resource

For a disk resource: make sure the Cluster Service account (usually NT AUTHORITY\SYSTEM or a domain-joined service account) has Full Control on the volume. Open Disk Management, right-click the volume → Properties → Security. If the account is missing, add it.

For a file share witness: the same goes for the share NTFS permissions and share permissions.

Step 4: Check for IP Conflicts or Stale DNS

If it's an IP Address resource, ping the IP from a different machine. If you get a reply, something else is using it. Also flush DNS on the node:

ipconfig /flushdns
Clear-DnsClientCache

Then try bringing the resource online again.

Step 5: Force Resource Restart via PowerShell

Sometimes the RHS process is hung. Force a restart:

Stop-ClusterResource "YourResourceName"
Start-ClusterResource "YourResourceName" -Wait

If it still fails, move the resource to another node and try again:

Move-ClusterResource "YourResourceName" -Node "OtherNodeName"

What to Check If It Still Fails

Validation Report — Run Test-Cluster on the entire cluster. It catches storage and network misconfigurations that you'd miss manually.
Disk Signature Collision — Two disks with the same signature on different nodes will cause this. Use diskpart or uniqueid disk to check and change one.
Quorum Configuration — If the cluster itself has a quorum issue, resources won't come online. Check quorum status in Cluster Manager → More Actions → Configure Cluster Quorum.
Windows Updates — I've seen KB5037768 for Server 2022 break cluster resources. Check if a recent update lines up with the problem.

If none of this works, open a case with Microsoft. Share the cluster log and the exact resource GUID. They'll dig into the RHS dump files.