Unable to set disk quota for Windows2025 containers

[winkingturtle-vmw]

Describe the bug We are in the process of upgrading to Windows Server 2025 and our initial testing is showing a regression from Windows Server 2019 by way of failing to set disk quota for containers. Previously, we have been able to enforce disk limit for each container.

To Reproduce

• docker run -it mcr.microsoft.com/windows/servercore:ltsc2025 powershell in one powershell
• mountvol.exe /L to get the the Volume GUID for the new container
• New-FSRMQuota -Path "\\?\Volume{GUID-FROM-ABOVE}\" -Size 10GB

New-FSRMQuota : 0x80045313, A required filter driver is not installed, loaded or ready
for service.
At line:1 char:1
+ New-FSRMQuota -Path "\\?\Volume{d7d5def4-b68d-43dd-b571-9eece130a16c} ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : NotSpecified: (MSFT_FSRMQuota:Root/Microsoft/.../MSFT_FSR
   MQuota) [New-FsrmQuota], CimException
    + FullyQualifiedErrorId : HRESULT 0x80045313,New-FsrmQuota

Expected behavior We expect to be able to set the disk limit for the volume the same way as Windows Server 2019. The same set of commands works for WindowsServer2019. If we need to install additional packages, it's unclear what else needs to be installed.

Configuration:

• Edition: Windows Server 2025 (Core or GUI)
• Base Image being used: Windows Server Core
• Container engine: docker
• Container Engine version [e.g. 22]

Additional context Add any other context about the problem here.

[github-actions[bot]]

Thank you for creating an Issue. Please note that GitHub is not an official channel for Microsoft support requests. To create an official support request, please open a ticket here. Microsoft and the GitHub Community strive to provide a best effort in answering questions and supporting Issues on GitHub.

[winkingturtle-vmw]

@ntrappe-msft We are blocked on making progress until we can apply disk quota for every container. Can you please provide some guidance on best path forward ?

[ntrappe-msft]

Are you also on a Server 2025 host?

[winkingturtle-vmw]

Yes, the host was the same version of the container version.

[winkingturtle-vmw]

@ntrappe-msft Can you let us know if this is being tracked on your side? We are blocked on moving forward.

[ntrappe-msft]

@winkingturtle-vmw Yes, it's being tracked. It may take a while for me to share meaningful updates as my backlog is full but I'm in the process of investigating it now.

[winkingturtle-vmw]

Hi @ntrappe-msft wanted to check back in on this issue and see if we can find a resolution for it so that we can continue our Windows2025 Server work. Do you have any updates for us ?

[ntrappe-msft]

Thanks for the ping. My backlog has been very full for the last few weeks so I haven't been able to dive in deep. I'll try to take a look by the end of the week and let you know if I have any recommendations by next week.

[cphi-vmw]

@ntrappe-msft - Any update on this? It's risking our ability to support Windows 2025 within Tanzu/Cloudfoundry.

[ntrappe-msft]

Could you confirm if the image you're using perfectly matches the host OS version? You can specify an exact match with the image by doing: mcr.microsoft.com/windows/servercore:-<version>.

[winkingturtle-vmw]

@ntrappe-msft I just pulled the latest patch on both my base WindowsServer2025 and containers to be ltsc2025-KB5062553 and I see the same error. Have you tried the reproduction steps above ? It's quite simple to reproduce this error regardless of what IaaS you are on.

[winkingturtle-vmw]

@ntrappe-msft Do you have any progress on this issue ?

[ntrappe-msft]

Due to ongoing improvements in container security and isolation boundaries, modern containers (post-2019) no longer support certain filter drivers such as fltMgr.sys. As a result, New-FSRMQuota and related FSRM enforcement mechanisms are not functional inside Server 2025 containers.

While FSRM itself is not supported in containers, you could consider the following approaches:

• Fixed-Size VHDX Volumes: VHD(X) files with defined sizes could be mounted into the container.
• User-Space Monitoring: You could track disk usage using scripts inside a container. It's not enforcement but you could have an alert for when you've passed a threshold.

Please let me know if you need to find a better workaround for your given scenario.

[winkingturtle-vmw]

@ntrappe-msft Our users rely on the ability to limit disk usage and if containers misbehave, It's expected to be rescheduled by the platform. Reading this document, our understanding is that NTFS supports Disk Quotas, so we are a bit surprised to find your comment above.

For clarification, for Fixed-Size VHDX Volumes option, are you suggesting that only the extra VHD disk can be limited and not the main container ? If so, this still doesn't solve the issue for enforcing hard limit on the container.

I don't know if either of those options are applicable for our platform since our users expect the container to be rescheduled if it reaches the disk limit.

I am not sure I fully understand the risk here for including fltMgr.sys, can you please elaborate what the risks are ? It seems to me that there is more risks in not being able to limit the disk usage. Do we have a way to include fltMgr.sys in our container base image ?

[ntrappe-msft]

Reading this document, our understanding is that NTFS supports Disk Quotas, so we are a bit surprised to find your comment above.

Just to clarify, the document reflects capabilities of the NTFS file system on Windows Server overall. But it does not account for what is removed or disabled in containerized environments.

[winkingturtle-vmw]

@ntrappe-msft

Fixed-Size VHDX Volumes: VHD(X) files with defined sizes could be mounted into the container.

Can you please clarify if your comment is referring to extra VHD disks or the main container ?

Due to ongoing improvements in container security and isolation boundaries, modern containers (post-2019) no longer support certain filter drivers such as fltMgr.sys

Can you please clarify the risks here ?

Please let me know if you need to find a better workaround for your given scenario.

We need to find a better workaround for this where the hard limit is applied. Do you have other suggestion?

[winkingturtle-vmw]

@ntrappe-msft Has there been any new development on this issue ?

[winkingturtle-vmw]

@ntrappe-msft Thank you for your attention to this matter. We are now going on 5 months since the opening of this issue and we still don't have a workaround. I asked a series of questions that we don't the answer to and we would like to still help our customers limit the container disk usage. I look forward to hearing what solution we can provide for this issue ?

[microsoft-github-policy-service[bot]]

This issue has been open for 30 days with no updates. @ntrappe-msft, please provide an update or close this issue.

[winkingturtle-vmw]

We still have this issue without having a workaround.