| 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 is file-to-tier placement metadata for the addressed volume, so the first investigation belongs there rather than in a generic “disk failure” bucket.
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.
Capture the exact object instance
| 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 |
Prove the condition 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.
Mechanism-specific note
Pinning is defined for supported file or volume objects. 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 that triggers this result.
- 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 operation.
- Telemetry includes both symbolic names when it or
ERROR_TIERING_FILE_IS_NOT_PINNEDoccurs again.
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.
- Microsoft: Optimize-Volume — use this source to verify tiering state and parameters.
- Microsoft: fsutil tiering — documents the supported management path relevant to this HRESULT.
Looking for a different code? Search another status or error code.
