| Previous | Next |
| FSRM_E_ERROR_NOT_ENABLED | FSRM_E_NO_EMAIL_ADDRESS |
FSRM_E_CANNOT_CREATE_TEMP_COPY
FSRM_E_CANNOT_CREATE_TEMP_COPY is the failure HRESULT 0x8004537C (signed decimal -2147200132, unsigned decimal 2147767164). Its severity bit is 1, facility is 4 (FACILITY_ITF), and the facility-specific code field is 0x537C.
FSRM cannot create a temporary copy of the file
This result means a File Server Resource Manager workflow needed a temporary file copy and could not create it. The public message does not identify the temporary directory or the component that requested the copy, so diagnostics must preserve the job, source file, module, and nested operating-system error rather than assuming one fixed location.
AllStat records the official condition as: “File Server Resource Manager could not create a temporary file copy.” The wording should be interpreted at this FSRM stage, not as a generic file-system or COM failure.
Where the failure boundary lies
The source file may have been selected and opened successfully; failure occurs when FSRM or a processing module prepares separate working content. This is distinct from a source sharing violation and from failure of the final move to an expiration directory. Temporary-copy creation can require free space, path access, metadata creation, and compatible file-system behavior.
Likely causes to separate
- The volume used for temporary data lacks enough free space or has reached a quota.
- The FSRM service or module identity cannot create files in the selected temporary directory.
- Antivirus, endpoint protection, or another process blocks the generated temporary name.
- Path length, invalid characters, encryption, offline state, or file-system features prevent a faithful working copy.
- A custom storage or classification module requests a temporary representation it cannot initialize.
Evidence worth preserving
- Capture the source path, source size, job and module names, free space, and the inner Win32 error from the Application log.
- Record the volume and directory actually used for temporary data if the event or module trace exposes them.
- Note whether the copy fails before content transfer, during streaming, or while applying attributes and security metadata.
- Compare one small local NTFS file with the failing file while keeping the same rule and module configuration.
Diagnostic sequence
- Check free space and quotas on both the source-related work volume and any configured module workspace.
- Test file creation under the service or module execution identity rather than only as an administrator.
- Review security-product events for blocked temporary files and use a narrow test exclusion only to prove causality.
- Inspect source attributes, EFS state, alternate streams, path length, and whether the file is available offline.
- If only one third-party module fails, use its documented workspace and logging settings instead of changing global TEMP variables blindly.
Retry and recovery
Correct the specific resource or access condition, remove abandoned temporary artifacts if their owner documents that as safe, and retry the individual file. Before replaying a destructive job, verify that the original file was not already moved or modified after the copy stage. More free disk space is not a complete remedy when the nested error indicates access, path, or module failure.
What this HRESULT does not establish
The HRESULT does not prove that the system temporary directory is full, and it does not establish that the source is unreadable. Without the nested error and module identity, changing permissions on broad directories is speculative and can weaken security.
Difference from nearby FSRM results
FSRM_E_FILE_IN_USE points to an incompatible source handle. FSRM_E_EXPIRATION_PATH_NOT_WRITEABLE validates the configured final expiration root, not an internal working copy.
Practical scenario
A classification module creates a working copy of a 12 GB archive on a nearly full service volume. Small files succeed, but this archive returns the HRESULT before module analysis starts. Free-space and module traces identify the work volume; after capacity is added, the single file is retried and completes.
Guidance for software and telemetry
Applications should surface the nested operating-system status and processing stage. Module authors should use collision-resistant names, close partial files on failure, enforce size limits, and document where temporary copies are stored.
Official Microsoft references
- Microsoft: MS-FSRM protocol error codes
- Microsoft: IFsrmFileManagementJob
- Microsoft: IFsrmClassificationManager
- Microsoft: IFsrmPropertyBag
- Microsoft: FSRM troubleshooting guidance
Looking for a different code? Search another status or error code.
