What does HRESULT 0x80045397 (FSRM_E_EXPIRATION_PATH_NOT_WRITEABLE) mean?

 
Previous Next
FSRM_E_CSC_PATH_NOT_SUPPORTED FSRM_E_EXPIRATION_PATH_TOO_LONG

FSRM_E_EXPIRATION_PATH_NOT_WRITEABLE

FSRM_E_EXPIRATION_PATH_NOT_WRITEABLE is the failure HRESULT 0x80045397 (signed decimal -2147200105, unsigned decimal 2147767191). Its severity bit is 1, facility is 4 (FACILITY_ITF), and the facility-specific code field is 0x5397.

The FSRM expiration destination is not writable

A file expiration task moves matching files into a configured expiration root. This HRESULT means the server cannot write to that destination. AllStat specifically directs administrators to grant Write permission to the computer account of the server performing expiration, which is different from proving that the interactive administrator can create a test file.

AllStat records the official condition as: “Cannot write to the specified expiration directory. Confirm that the permissions of the expiration directory grant Write permission to the computer account of the server performing the file expiration task.” The wording should be interpreted at this FSRM stage, not as a generic file-system or COM failure.

Where the failure boundary lies

The failure concerns the destination root used by the expiration job. The source namespace may be readable and the selection conditions may be correct. Microsoft’s contract requires a valid local directory that the FSRM service can write to; remote or identity-dependent designs must be validated under the actual service execution context.

Likely causes to separate

  • The server computer account or service context lacks Create Folder, Create Files, Write Attributes, or required traversal rights.
  • Explicit deny entries or broken inheritance override a broad allow entry.
  • The destination was replaced, restored, or moved and now has different ownership or ACLs.
  • A security product, file screen, quota, or storage policy blocks creation despite apparent NTFS permissions.
  • The path resolves differently for the service than it does for the administrator who tested it.

Evidence worth preserving

  • Record the exact configured expiration directory, server computer account, ACL, owner, inheritance state, and nested access error.
  • Capture free space, quota and file-screen policy on the destination because write failure is not limited to ACL evaluation.
  • Test creation under the service-equivalent identity and from the actual FSRM server.
  • Preserve the job report showing whether validation failed before any source file was moved.

Diagnostic sequence

  • Confirm that the destination is local to the server as required by the documented job contract.
  • Evaluate effective access for the computer or service identity, including share permissions if a management layer supplied a network path.
  • Check that each parent directory can be traversed and that inheritance reaches newly created job subdirectories.
  • Inspect FSRM file screens, quotas, antivirus and controlled-folder policies for a separate denial.
  • Create and remove a uniquely named test directory without modifying production expired files.

Retry and recovery

Grant the minimum required access to the correct server identity or choose a supported writable local NTFS destination. Then validate creation and removal of a test directory before rerunning the job. Do not grant broad permissions to Everyone merely because an administrator test succeeded under the wrong identity.

What this HRESULT does not establish

The HRESULT does not state that source files are unreadable and does not prove that the destination is missing. It also does not distinguish ACL denial from quota, file-screen, or security-filter rejection without the nested event.

Difference from nearby FSRM results

FSRM_E_EXPIRATION_PATH_TOO_LONG rejects the configured string length, and FSRM_E_EXPIRATION_VOLUME_NOT_NTFS rejects the destination file system. This value is specifically about write capability.

Practical scenario

An expiration task targets a newly restored directory whose ACL grants administrators full control but omits the file server computer account. Manual testing succeeds for the administrator, while FSRM returns this HRESULT. Effective-access testing identifies the identity mismatch, the ACL is corrected narrowly, and the job is rerun.

Guidance for software and telemetry

Deployment code should validate the path using the same server-side identity and log the security principal used. Configuration UI should separate “path exists” from “FSRM can write here.”

Official Microsoft references

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