| Previous | Next |
| ERROR_TIERING_ALREADY_PROCESSING | ERROR_TIERING_FILE_IS_NOT_PINNED |
ERROR_TIERING_CANNOT_PIN_OBJECT
What this result says about the disk model: tiering cannot pin object
ERROR_TIERING_CANNOT_PIN_OBJECT (0x80830007) is emitted by the tiering path when the target is not a regular file or supported volume object that the tiering provider can associate with a desired tier. The deciding object for it is file-to-tier placement metadata for the addressed volume, so the first investigation belongs there rather than in a generic “disk failure” bucket for it.
Storage tiering operates above a tiered Storage Spaces virtual disk and records desired placement separately from normal file allocation for it. 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.
The standard message identifies the immediate condition, but this result also requires the producer API, object topology and attempted state transition. Capture them before an automatic refresh advances the storage generation for it.
Capture the exact object generation
| Storage diagnostic field | Value |
|---|---|
| Narrow experiment | apply the operation to a regular file on a verified tiered volume, then compare with the original object type and pin state |
| Closest comparison | ERROR_TIERING_FILE_IS_NOT_PINNED |
| Owning object | file-to-tier placement metadata for the addressed volume |
| Rejected invariant | the target is not a regular file or supported volume object that the tiering provider can associate with a desired tier |
| Identity and generation | volume GUID path, storage-space and tier IDs, file ID plus file-system identity, cluster owner node, optimization job state and requested pin target |
Keep this HRESULT as the primary result if rollback or cleanup reports another code; those later values describe recovery, not the first rejected invariant.
Prove the boundary in a test volume
- Capture the API parameters and object map that led to this result; do not begin with cleanup.
- Build a passing control with the same disks or image copy and preserve volume GUID path, storage-space and tier IDs, file ID plus file-system identity, cluster owner node, optimization job state and requested pin target.
- Run the narrow transition described here: apply the operation to a regular file on a verified tiered volume, then compare with the original object type and pin state.
- Compare resulting IDs, counts, health and ownership to prove the caller crossed the result invariant rather than suppressing it.
A useful diagnostic fork is ERROR_TIERING_FILE_IS_NOT_PINNED versus this result. This code concerns the target is not a regular file or supported volume object that the tiering provider can associate with a desired tier; the alternate code should remain observable after the fix, proving the application did not suppress the entire subsystem for it.
Mechanism-specific note
Pinning is defined for supported file or volume objects for it. Record file attributes, reparse-point status and whether the object belongs to the tiered volume. Directories, unsupported reparse targets or files on another volume should be rejected by the caller before invoking the tier provider.
Safe recovery path
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. Apply the change through the supported storage API, then close and reacquire affected objects before retrying.
- The controlled A/B case changes only the invariant responsible for it.
- No unrelated disk, cluster owner, tier policy or virtual-disk backing file is altered to hide this result.
- Health, synchronization or job state reaches a terminal value consistent with the repaired the operation.
- Telemetry includes both symbolic names when it or
ERROR_TIERING_FILE_IS_NOT_PINNEDoccurs again.
A reboot, blanket disk conversion or deletion of storage metadata is not a justified first response to it; it changes multiple invariants and can erase the evidence needed to identify the defect.
Technical references
- Microsoft: MSFT_FileStorageTier class — defines the tiering objects used to interpret it.
- Microsoft: Set method of MSFT_FileStorageTier — primary API or object-model reference for the boundary.
- Microsoft: Optimize-Volume — use this source to verify tiering state and parameters for it.
- Microsoft: fsutil tiering — documents the supported management path relevant to it.
Looking for a different code? Search another status or error code.