FSRM Hard Quota Bypass on ReFS Storage Volumes

Sarah 20 Reputation points
2026-09-09T08:01:53.6066667+00:00

We have identified an issue where storage quotas on our ReFS file shares are not being properly enforced by File Server Resource Manager (FSRM).

_Symptom: Users can write data beyond their allocated hard quota limit on ReFS volumes; expected write blocks are not triggering.

_Root Cause: Suspected detachment or corruption of the FSRM minifilter driver integration on ReFS volume structures.

_Impact: Risk of unmonitored storage exhaustion on primary file shares.

Proposed Action Plan:

_Audit current filter driver status across all ReFS mounts (fltmc instances).

_Re-register the FSRM minifilter driver and restart the srmsvc service.

_Reinitialise quota enforcement on the affected paths via PowerShell (Update-FsrmQuota).

Has anyone run into this specific ReFS driver binding issue on Windows Server recently? Please drop any notes in the thread before we schedule the fix during the upcoming maintenance window.

Windows for business | Windows 365 Business
0 comments No comments

1 answer

Sort by: Most helpful
  1. Domic Vo 32,060 Reputation points Independent Advisor
    2026-09-09T08:41:12.8233333+00:00

    Hello,

    your description matches a limitation that has been observed with File Server Resource Manager when used on ReFS volumes. On NTFS, the SRM minifilter driver (srmmf.sys) attaches cleanly and enforces hard quotas, but on ReFS the binding can fail or detach, leaving quotas unenforced even though they appear configured. This explains why users can continue writing beyond their quota without being blocked.

    The first step is to confirm whether the filter driver is actually bound to the ReFS mount. Run fltmc instances and check if srmmf is listed against the affected volume. If it is missing or shows as detached, quota enforcement will not work. Restarting the srmsvc service alone will not fix this; you need to reload the minifilter with fltmc load srmmf and remount the ReFS volume so the binding is re‑established.

    Once the driver is correctly attached, reinitialize the quotas with PowerShell. Use Update-FsrmQuota -Path "X:\Share" to refresh enforcement flags on the affected paths. After that, verify with Get-FsrmQuota and perform a controlled write test to confirm that the hard quota is now blocking as expected.

    It is also important to monitor the File Server Resource Manager event logs under Applications and Services Logs > File Server Resource Manager. You should see entries like “FSRM quota enforcement started” once the binding is healthy. If instead you see repeated errors such as “Unsupported file system,” that indicates your current Windows Server build does not fully support quota enforcement on ReFS. In that case, the only reliable workaround is to migrate critical shares back to NTFS or enforce quotas at the storage subsystem level (for example, Storage Spaces Direct or SAN‑level quotas).

    In short, check the filter binding with fltmc, reload the minifilter if necessary, restart srmsvc, and refresh quotas with Update-FsrmQuota. If enforcement still fails, you are hitting a ReFS limitation and should plan for NTFS or alternative quota enforcement mechanisms.

    I hope you've found something useful here. If it helps you get more insight into the issue, it's appreciated to accept the answer. Should you have more questions, feel free to leave a message. Have a nice day!

    Domic Vo.

    Was this answer helpful?

    0 comments No comments

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.