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.

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.

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

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.

One-variable reproduction

1. Create a nonproduction case 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. Keeping both names prevents a generic storage label from hiding the actual owner.

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 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 relevant lifecycle transition, such as reopen, remount, owner change or detach/attach.
• The application still distinguishes it from ERROR_TIERING_NOT_SUPPORTED_ON_VOLUME and has no unbounded retry loop.

Technical references

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