What does HRESULT 0x80045396 (FSRM_E_CSC_PATH_NOT_SUPPORTED) mean?

Status / error code:

Category:

Constant name:

Source:

Facility:

Operating System:

Description:

FSRM cannot perform this operation on a path where Offline Files client-side caching is enabled.

Previous	Next
FSRM_E_LEGACY_SCHEDULE	FSRM_E_EXPIRATION_PATH_NOT_WRITEABLE

FSRM_E_CSC_PATH_NOT_SUPPORTED

FSRM_E_CSC_PATH_NOT_SUPPORTED is the failure HRESULT 0x80045396 (signed decimal -2147200106, unsigned decimal 2147767190). Its severity bit is 1, facility is 4 (FACILITY_ITF), and the facility-specific code field is 0x5396.

The selected path uses Offline Files and is unsupported for this FSRM operation

The HRESULT states that the requested File Server Resource Manager operation is not supported for a path on which Offline Files, also known as Client-Side Caching (CSC), is enabled. The relevant path can be a share or namespace that participates in caching semantics even when the server’s local directory appears to be an ordinary NTFS folder.

AllStat records the official condition as: “This operation is not supported for paths on which Offline Files is enabled.” The wording should be interpreted at this FSRM stage, not as a generic file-system or COM failure.

Where the failure boundary lies

FSRM jobs and classification operate on authoritative server files. Offline Files introduces cached copies, synchronization, pinning, and client availability behavior that can make the target state ambiguous for the rejected operation. The code is a capability restriction, not a report that the cache is currently disconnected or corrupt.

Likely causes to separate

The SMB share containing the job scope is configured to allow or require Offline Files caching.
A DFS path resolves to a target whose share has CSC enabled even though another target is configured differently.
The path was moved to a share with a caching policy incompatible with the existing FSRM job.
Automation validates the local path but omits the share-level caching configuration seen by the workflow.

Evidence worth preserving

Record both the local namespace root and every SMB or DFS path through which the data is exposed.
Capture the caching mode of the active share and the DFS referral target selected during the failure.
Identify the exact FSRM operation because not every read-only management query has the same path restrictions.
Note client pinning or synchronization policy only as supporting context; the server share setting is the primary capability evidence.

Diagnostic sequence

Resolve the namespace to the actual file server and share rather than inspecting only the friendly DFS name.
Verify the share caching configuration and whether Offline Files is required by business continuity policy.
Test the same FSRM operation on a controlled non-cached NTFS share to confirm the capability boundary.
Assess the effect on mobile users before disabling caching; an FSRM fix must not silently remove an established offline-access requirement.
If both features are needed, redesign the data placement or run the policy on a supported authoritative path.

Retry and recovery

Move the FSRM scope to a supported path or change the share caching policy only after evaluating client synchronization and availability requirements. Retry after the server confirms the new share configuration. Clearing a client cache alone does not change the server-side unsupported-path contract.

What this HRESULT does not establish

The HRESULT does not prove that any client currently has a cached copy and does not indicate an Offline Files synchronization error. It also does not say the underlying volume is non-NTFS.

Difference from nearby FSRM results

FSRM_E_EXPIRATION_VOLUME_NOT_NTFS rejects the file system of an expiration destination. This code rejects a path capability associated with Offline Files, even when the server volume itself is NTFS.

Practical scenario

A file-management task is moved under a DFS namespace whose new target share is configured for Offline Files. The job definition still references a valid local folder, but execution returns this code. The storage team places the managed data on a non-cached authoritative share and retains Offline Files for a separate user-facing replica.

Guidance for software and telemetry

Configuration validators should inspect share and DFS target properties, not only call a local directory existence check. User-facing errors should explain the caching conflict instead of suggesting an unrelated permission change.

Official Microsoft references

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