What does HRESULT 0x80830005 (ERROR_TIERING_WRONG_CLUSTER_NODE) mean?

ERROR_TIERING_WRONG_CLUSTER_NODE

Locate the rejected storage invariant: tiering wrong cluster node

The practical meaning of ERROR_TIERING_WRONG_CLUSTER_NODE (0x80830005) is tied to file-to-tier placement metadata for the addressed volume: the request ran on a cluster node that does not currently own the metadata volume used for tier decisions. The result does not, by itself, prove file-system corruption or physical-media failure for it.

Storage tiering operates above a tiered Storage Spaces virtual disk and records desired placement separately from normal file allocation. Optimization may move data according to heat, whereas pinning expresses an explicit placement preference for a supported file or volume object. This object model determines which identifiers, counts and ownership state are meaningful.

Keep the first result attached to its request parameters and object generation while diagnosing this result. Cleanup failures or a later drive-letter change are secondary evidence, not replacements for the original boundary.

Evidence to preserve before repair

When it is followed by a secondary cleanup failure, store both codes with timestamps and retain this one as the initiating result for it.

One-variable reproduction

1. Create a nonproduction case for it that preserves the same geometry and ownership model.
2. Collect volume GUID path, storage-space and tier IDs, file ID plus file-system identity, cluster owner node, optimization job state and requested pin target before invoking the first mutating API.
3. Change one condition only: run the unchanged operation first on a nonowner node and then on the node that owns the metadata volume.
4. Re-enumerate after the transition and confirm this result is not reproduced by a stale handle from the old generation.

Use ERROR_TIERING_NOT_SUPPORTED_ON_VOLUME as the nearest comparison. This result is specific to the request ran on a cluster node that does not currently own the metadata volume used for tier decisions; the neighboring result belongs to another validation or lifecycle branch while diagnosing it. Keeping both names prevents a generic storage label from hiding the actual owner while diagnosing it.

Mechanism-specific note

Tier metadata operations are owner-sensitive in a failover cluster. Capture the owner immediately before the call and any concurrent failover event. Forward the request or retry after ownership stabilizes; repeatedly issuing it on every node can create competing optimization work.

Repair without rewriting unrelated metadata

Re-enumerate the volume, its storage tiers and the file object on the owner node; serialize optimization jobs and apply pinning only to supported objects on a live tiered volume. The result repair is incomplete until a fresh enumeration and new handle observe the corrected state.

• The original request now reaches success or a documented later status with the intended layout and access mode.
• A new enumeration reports internally consistent IDs, counts, geometry and ownership for the object corrected after this result.
• The passing state survives the lifecycle transition relevant to it, such as reopen, remount, owner change or detach/attach while diagnosing it.
• The application still distinguishes it from ERROR_TIERING_NOT_SUPPORTED_ON_VOLUME and has no unbounded retry loop.

Do not use it as a reason to edit dynamic-disk sectors, VHDX metadata, RCT sidecars or snapshot support files directly. Unsupported edits can turn a recoverable state mismatch into persistent corruption.

Technical references

• Microsoft: MSFT_FileStorageTier class — use this source to verify tiering state and parameters for it.
• Microsoft: Set method of MSFT_FileStorageTier — documents the supported management path relevant to it.
• Microsoft: Optimize-Volume — defines the tiering objects used to interpret it.
• Microsoft: fsutil tiering — primary API or object-model reference for the boundary.

Looking for a different code? Search another status or error code.