What does HRESULT 0x80045393 (FSRM_E_CANNOT_REMOVE_READONLY) mean?

 
Previous Next
FSRM_E_ADR_NOT_DOMAIN_JOINED FSRM_E_FILE_MANAGEMENT_JOB_INVALID_CONTINUOUS_CONFIG

FSRM_E_CANNOT_REMOVE_READONLY

FSRM_E_CANNOT_REMOVE_READONLY is the failure HRESULT 0x80045393 (signed decimal -2147200109, unsigned decimal 2147767187). Its severity bit is 1, facility is 4 (FACILITY_ITF), and the facility-specific code field is 0x5393.

FSRM cannot remove the file read-only attribute

This result means File Server Resource Manager attempted to clear the read-only attribute from a selected file and the operation failed. The read-only bit is distinct from NTFS discretionary access control, volume read-only state, and an incompatible open handle, although any of those surrounding conditions can prevent the transition.

AllStat records the official condition as: “File Server Resource Manager could not remove the read-only attribute from a file.” The wording should be interpreted at this FSRM stage, not as a generic file-system or COM failure.

Where the failure boundary lies

The file has already reached a stage where an FSRM workflow wants to modify, move, replace, or otherwise process it. Clearing the attribute is a prerequisite for that action, not proof that the final action itself has started. The public HRESULT does not name the job type, so the job report and event data are required to locate the stage.

Likely causes to separate

  • The FSRM service or action identity lacks permission to change file attributes.
  • The underlying volume, snapshot, media, or storage policy presents the object as read-only.
  • Another application changes or locks the file while FSRM attempts the attribute update.
  • A filter driver, synchronization client, or storage provider rejects attribute modification.
  • The file is an offline placeholder or protected object whose provider controls metadata transitions.

Evidence worth preserving

  • Capture the full file path, current attributes, volume state, job action, service identity, and nested Win32 result.
  • Record the ACL and ownership separately from the DOS read-only attribute so the two mechanisms are not conflated.
  • Check whether the attribute can be changed under the same execution identity on a test copy in the same directory.
  • Preserve filter-driver, Offline Files, antivirus, and storage-provider events around the attempted update.

Diagnostic sequence

  • Verify whether only the file attribute is set or the entire volume is write-protected or mounted read-only.
  • Test attribute modification with a controlled copy while retaining the original as evidence.
  • Check for an active handle or provider placeholder that prevents metadata writes.
  • Review custom file-management commands for code that re-applies attributes or changes ownership before FSRM finishes.
  • Avoid recursively clearing read-only flags across the namespace; that can alter files unrelated to the failed job.

Retry and recovery

Remove the specific write restriction or grant the required attribute-change access, then retry the individual file after confirming that its classification and job conditions still match. If a storage provider intentionally enforces read-only semantics, move the policy to a supported writable copy instead of defeating the provider. A retry without a changed attribute or storage state is not useful.

What this HRESULT does not establish

This HRESULT does not prove that the file contents are read-only in an application-specific sense, and it does not identify whether the failure came from ACLs, media state, a filter driver, or a race. It also does not mean every file in the job failed.

Difference from nearby FSRM results

FSRM_E_FILE_IN_USE identifies an incompatible open handle. FSRM_E_CANNOT_CREATE_TEMP_COPY concerns creation of a working file, while this code concerns changing an attribute on the selected object.

Practical scenario

A file-management task selects documents restored from read-only media. FSRM can enumerate and classify them but cannot clear the attribute required before its custom action, returning this HRESULT. The administrator stages writable copies on NTFS and reruns the task only for those files.

Guidance for software and telemetry

Log attributes as a bitmask and preserve the underlying operating-system error. Automation should not respond by globally issuing a recursive attribute-clear command; remediation must be scoped to the job and storage contract.

Official Microsoft references

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