Troubleshooting: Resolving 'Unable to Access ClusterStorage Folder' Errors on Windows Server

Table of Contents

Cluster Shared Volumes (CSV) are a foundational component for highly available virtual machines and applications in Windows Server Failover Clusters. They enable multiple nodes in a cluster to simultaneously access the same shared storage, streamlining management and facilitating features like Live Migration. However, encountering errors where a passive (non-coordinator) node cannot access a CSV volume, often indicated by event IDs 5120 or 5142, can severely disrupt cluster operations and compromise workload availability. This issue typically manifests as explorer hanging when attempting to access a CSV volume from a non-owning node, signaling a critical communication breakdown within the cluster’s storage fabric.

Understanding Cluster Shared Volumes (CSV) Architecture¶

To effectively troubleshoot CSV access issues, it’s crucial to understand how Cluster Shared Volumes function within a Failover Cluster. In a CSV environment, one node is designated as the “coordinator” or “owner” for a specific CSV LUN. All direct I/O operations for that LUN initially pass through this coordinator node. Other nodes in the cluster, referred to as “passive” or “non-coordinator” nodes, perform their I/O operations by redirecting them over the network via Server Message Block (SMB) to the coordinator node. This redirected I/O mechanism is fundamental to CSV’s operation and explains why network connectivity and SMB protocol configuration are paramount.

The efficiency and reliability of CSV heavily depend on robust and correctly configured inter-node network communication. Any disruption or misconfiguration in the network paths used for this SMB redirection can lead to severe performance degradation or, as in the cases discussed here, complete loss of access to the CSV volume from passive nodes. Therefore, maintaining optimal network health and configuration is not just a best practice but a strict requirement for stable CSV performance.

Symptoms of CSV Access Issues¶

When a passive node is unable to access a CSV volume, several distinct symptoms and error messages may appear in the event logs, indicating a failure in the SMB-based redirected I/O path. These events provide critical clues about the nature of the underlying problem. The most common indicators are specific Event IDs from the Microsoft-Windows-FailoverCluster source.

Event ID 5120¶

Event ID 5120 is a common error indicating that a Cluster Shared Volume is no longer available on a particular node. This event is typically logged when a problem occurs in connecting over the network using SMB to the owning (coordinator) node. While I/O might be temporarily queued, persistent issues will lead to significant performance problems or complete loss of access.

Here are the variations of Event ID 5120 and their meanings:

• Description: Cluster Shared Volume “volume_name” is no longer available on this node because of ‘STATUS_BAD_NETWORK_PATH(c00000be)’. All I/O will temporarily be queued until a path to the volume is re-established.

  • This specific error code signifies that the network path to the SMB2 share, which is created by the current CSV owner node, cannot be located. It suggests a fundamental networking issue preventing the non-owning node from establishing a connection to the owner. This could stem from incorrect IP addressing, DNS resolution failures, or even firewall blocks.

• Description: Cluster Shared Volume “volume_name” is no longer available on this node because of ‘STATUS_CONNECTION_DISCONNECTED(c000020c)’. All I/O will temporarily be queued until a path to the volume is reestablished.

  • This error code indicates that a node has lost its established connection to the SMB2 share hosted by the CSV owner. Unlike STATUS_BAD_NETWORK_PATH, which suggests an inability to find the path initially, this error implies that a connection was previously active but has since been severed. This often points to transient network interruptions, network adapter failures, or issues on the owner node itself that cause connection drops.

• Description: Cluster Shared Volume “volume_name” is no longer available on this node because of ‘STATUS_MEDIA_WRITE_PROTECTED(c00000a2)’. All I/O will temporarily be queued until a path to the volume is reestablished.

  • This error message is particularly concerning as it typically indicates a loss of disk reservation or direct I/O capabilities for the volume. While the primary cause for this article focuses on network issues affecting SMB, a STATUS_MEDIA_WRITE_PROTECTED error can occur if the network communication required to maintain the disk reservation between nodes fails. It essentially means the cluster node cannot write to the volume, often because it believes the disk is write-protected, highlighting a deeper storage or connectivity issue.

Event ID 5142¶

• Description: Cluster Shared Volume “volume_name” (‘Cluster Disk #’) is no longer accessible from this cluster node because of error ‘ERROR_TIMEOUT(1460)’. Please troubleshoot this node’s connectivity to the storage device and network connectivity.
  • Event ID 5142 is a more severe indication that the non-owning node has not only lost access but the Cluster Shared Volume is no longer queuing I/O. This means that instead of experiencing slow responses due to queued I/O, virtual machines or applications on the affected node will see the storage as completely disconnected. The ERROR_TIMEOUT (1460) suggests a prolonged inability to communicate with the coordinator node or the underlying storage, leading to the cluster marking the path as completely inaccessible. This typically requires immediate intervention as it directly impacts workload availability.

Core Cause: SMB Network Dependency¶

The fundamental reason behind these CSV access errors from passive nodes lies in their reliance on Server Message Block (SMB) for redirected I/O. When a passive node performs an I/O operation to a CSV volume, it doesn’t directly access the storage. Instead, it sends the I/O request over the network via SMB to the coordinator node, which then performs the actual I/O operation on the shared storage.

For this SMB communication to function correctly on the network adapters designated for cluster use, specific network protocols must be enabled:

1. Client for Microsoft Networks: This component allows a computer to access resources on other Microsoft Windows-based computers. It is essential for initiating SMB client connections from the passive node to the coordinator node.
2. File and Printer Sharing for Microsoft Networks: This component allows a computer to share its own resources (like files and printers, or in this case, the SMB share representing the CSV volume) with other computers on the network. It is crucial for the coordinator node to host the SMB share that passive nodes connect to.

If either of these protocols is disabled or misconfigured on the network adapters used for cluster communication, the SMB connection required for redirected I/O will fail. This directly leads to the symptoms and event IDs described above, as the passive node loses its ability to communicate with the CSV owner for storage access.

Illustrating CSV I/O Path¶

```mermaid
graph TD
subgraph Cluster Shared Volume (CSV) I/O Flow
A[Passive Node] →|Redirected I/O (SMB)| B(Cluster Network)
B → C[Coordinator Node]
C →|Direct I/O| D[Shared Storage (SAN/DAS)]
D → C
C →|SMB Response| B
B → A
end

style A fill:#f9f,stroke:#333,stroke-width:2px
style C fill:#f9f,stroke:#333,stroke-width:2px
style D fill:#bbf,stroke:#333,stroke-width:2px
style B fill:#ccf,stroke:#333,stroke-width:2px

```
The diagram above illustrates the redirected I/O path for Cluster Shared Volumes. Passive nodes communicate with the coordinator node over the cluster network using SMB for all I/O operations, which are then processed directly by the coordinator node on the shared storage.

Resolution: Verifying Network Adapter Protocols¶

The primary resolution for ‘Unable to Access ClusterStorage Folder’ errors involves ensuring that the necessary network protocols are correctly enabled on all cluster network adapters. This step must be performed on each cluster node, as consistent configuration across the entire cluster is vital for seamless operation.

Step-by-Step Configuration Verification¶

Follow these steps on every node in your Windows Server Failover Cluster:

1. Access Network Connections:

   • Click Start, then click Run.
   • Type ncpa.cpl into the Run dialog box.
   • Click OK or press Enter. This action opens the Network Connections window, displaying all network adapters configured on the server.

2. Identify Cluster Network Adapters:

   • Carefully identify the network adapters that are actively used for cluster communication. In many setups, there might be multiple adapters for different purposes (e.g., Management, Live Migration, iSCSI, Cluster Heartbeat). It’s crucial to examine all network adapters that the cluster uses or might use. The Cluster Network reports often provide details on which networks are enabled for cluster use.

3. Check Adapter Properties:

   • Right-click on each identified cluster network adapter (e.g., “Local Area Connection,” “Ethernet,” or custom-named adapters).
   • Select Properties from the context menu. This will open the network adapter’s properties dialog box, showing a list of items that the connection uses.

4. Verify Protocol Presence and Selection:

   • Within the “This connection uses the following items” box, ensure that both Client for Microsoft Networks and File and Printer Sharing for Microsoft Networks are present and their respective checkboxes are selected.
   • These two protocols are fundamental for SMB communication, allowing the nodes to act as both clients (to access CSV shares) and servers (to host CSV shares when they become the coordinator).

Adding Missing Protocols¶

If either protocol is missing from the list, you must install it:

1. In the network adapter’s properties dialog box, click the Install… button.
2. In the “Select Network Component Type” dialog box, choose Client, then click Add….
3. Select Client for Microsoft Networks from the list, click OK, and then click Yes if prompted.
4. Repeat the process for File and Printer Sharing for Microsoft Networks:
   • Click Install… again.
   • Choose Service, then click Add….
   • Select File and Printer Sharing for Microsoft Networks from the list, click OK, and then click Yes if prompted.

After adding any missing protocols, verify that their checkboxes are selected. No reboot is typically required for these changes to take effect, but a network adapter disable/enable cycle or a refresh of cluster services might be beneficial if issues persist.

In-Depth Analysis of Related Concepts¶

Beyond the direct resolution, understanding the underlying mechanisms and related configurations can aid in comprehensive troubleshooting and prevention of future issues.

Cluster Network Metric¶

Failover Clusters assign a metric value to each network adapter configured for cluster use. The network with the lowest cluster network metric value is considered the “preferred” network for inter-node communication, including redirected I/O for CSV. If this preferred network becomes unavailable due to problems or reconfiguration, the cluster’s network fault tolerance mechanisms will automatically switch to the network with the next lowest metric.

Importance: If the failover network is not properly configured with Client for Microsoft Networks and File and Printer Sharing, even if the primary preferred network is correct, a network disruption could still lead to CSV access issues. Therefore, it is highly recommended that any network that the cluster might potentially use (i.e., any network not explicitly disabled for cluster use) should be configured as described above to allow full CSV functionality.

You can inspect cluster network metrics using PowerShell:

Get-ClusterNetwork | Format-Table Name, Metric, Role

This command provides insight into which networks are considered primary and secondary for cluster communication.

SMB Diagnostics¶

For more advanced troubleshooting of SMB connectivity, consider using these PowerShell cmdlets:

• Get-SmbConnection: Shows active SMB client connections from the local computer. You should see connections to the coordinator node’s IP for CSV volumes.
• Get-SmbShare: Displays SMB shares hosted on the local computer. When a node is the coordinator, it automatically creates an internal SMB share for the CSV volume.
• Test-NetConnection -ComputerName <CoordinatorNodeIP> -Port 445: This command tests TCP connectivity to port 445 (the default SMB port) on the coordinator node. A successful connection is vital for SMB communication.

Firewall Considerations¶

Windows Firewall or any third-party firewalls can block SMB traffic if not configured correctly. Ensure that inbound and outbound rules allow SMB (port 445 TCP) communication between all cluster nodes on the cluster networks. Generally, when you enable “File and Printer Sharing for Microsoft Networks,” the necessary firewall rules are automatically created, but it’s a common point of failure for manual inspection.

Network Adapter Drivers and Teaming¶

Outdated or corrupted network adapter drivers can cause intermittent connectivity issues that manifest as CSV access problems. Always ensure that network adapter drivers are up to date and compatible with your Windows Server version. If using network adapter teaming (NIC Teaming), verify that the teaming configuration is robust and doesn’t introduce any network complexities that could disrupt SMB traffic.

Underlying Storage Connectivity¶

While this article focuses on network issues, it’s important to remember that CSV relies on underlying shared storage. Ensure that all nodes have healthy, consistent connectivity to the shared storage (e.g., Fibre Channel, iSCSI, SAS). Issues at the storage layer, such as zoning problems, LUN masking issues, or storage device failures, can also lead to CSV inaccessibility, sometimes with symptoms similar to network problems. Always check your storage system’s logs and connectivity status if network troubleshooting doesn’t resolve the issue.

Prevention and Best Practices¶

To minimize the occurrence of CSV access issues, consider implementing the following best practices for your Windows Server Failover Cluster:

• Dedicated Cluster Networks: Whenever possible, use dedicated network adapters and subnets for cluster communication, including CSV traffic. This isolates critical cluster traffic from general network traffic, reducing congestion and potential interference.
• Consistent Configuration: Ensure that all network adapters participating in the cluster communication have identical and correct configurations across all cluster nodes. Inconsistencies are a frequent source of problems.
• IP Address Management: Use static IP addresses for all cluster network adapters. Dynamic IP addresses (DHCP) are generally not recommended for stable cluster operations.
• Regular Health Checks: Periodically review cluster validation reports, event logs, and network configurations to proactively identify and address potential issues before they cause downtime.
• Firmware and Driver Updates: Keep network adapter firmware and drivers updated to the latest stable versions provided by the hardware vendor.
• Avoid Over-Consolidation: While NIC Teaming is powerful, avoid overly complex network configurations that might inadvertently introduce single points of failure or make troubleshooting difficult. Simple, dedicated network paths are often more reliable for core cluster functions.

Conclusion¶

Resolving ‘Unable to Access ClusterStorage Folder’ errors on Windows Server Failover Clusters primarily hinges on understanding and correctly configuring the network protocols essential for Cluster Shared Volume (CSV) communication. The reliance on SMB for redirected I/O from passive nodes makes “Client for Microsoft Networks” and “File and Printer Sharing for Microsoft Networks” indispensable. By systematically verifying and, if necessary, enabling these protocols on all cluster-aware network adapters, administrators can restore critical CSV access and ensure the high availability of their clustered workloads. Proactive network configuration, diligent monitoring, and adherence to best practices will significantly reduce the likelihood of encountering these disruptive issues.

We hope this comprehensive guide assists you in troubleshooting and preventing CSV access problems in your Windows Server environments. Do you have any additional tips or experiences with these errors that you’d like to share? Please feel free to comment below and join the discussion!