docker build fails when dockerd data-root is on NVMe Direct Disk
Nobody has claimed this yet.
Assessment
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Newbie friendliness
- 45/100
- Issue type
- Bug
- Clarity
- Mostly clear
- Activity status
- Active
- Tech stack
- docker, kubernetes, powershell
- Domain
- devops, infrastructure, operating-systems
Research direction
Start by reproducing docker build -t test . with dockerd HostProcess and compare the HCS/windowsfilter path when data-root is on NVMe versus SSD. Inspect the point where scratch.vhdx is created or mounted; done means Windows-native image builds succeed with the NVMe data-root configuration.
Written by the indexing model from the issue text.
Description
Describe the bug
On Windows Server Kubernetes nodes:
- When Docker’s
data-rootis on SSD (ATA bus) →docker buildworks correctly. - When Docker’s
data-rootis on NVMe Direct Disk →docker buildconsistently fails with:
hcsshim::System::Start: failure in a Windows system call:
The process cannot access the file because it is being used by another process.
At the same time, Kubernetes workloads using containerd run fine with NVMe storage (pods pull images and start normally).
The issue is isolated to the dockerd HostProcess build workflow (image builds).
To Reproduce
Steps to reproduce the behavior:
- Configure Docker HostProcess
daemon.json:{ "data-root": "G:\\docker", "exec-opts": ["isolation=process"], "debug": true } - Restart
vmcompute,hns, anddockerservices. - Run:
docker build -t test . - Observed result:
hcsshim::System::Start: failure in a Windows system call: The process cannot access the file because it is being used by another process. - Reconfigure Docker with
data-rooton SSD (C:\docker-data). - Restart services.
- Re-run build.
- Expected result: build succeeds.
Expected behavior
docker build should succeed with data-root on NVMe Direct Disks, just as it does on SSD.
Configuration:
- Edition: Windows Server 2022 Datacenter Core (Azure AKS Windows nodepool)
- Base Image:
mcr.microsoft.com/windows/servercore:ltsc2022 - Container engine: Docker (
dockerdHostProcess), containerd (for Kubernetes runtime) - Container engine version: Docker 20.10.x / 24.x (reproducible across versions)
Disk info (NVMe drive G:):
File System : NTFS
Bytes Per Cluster : 4096
Compression/Dedup/Encryption : disabled
HealthStatus : Healthy
OperationalStatus : OK
Additional context
- Kubernetes pods (containerd) run fine with NVMe Direct Disk storage.
- dockerd HostProcess fails only during builds when
data-rootis on NVMe. - Issue occurs at the moment dockerd/HCS tries to create or mount
scratch.vhdxinwindowsfilter.
Tests attempted (all failed on NVMe data-root):
- Disabled Windows Defender completely (Tamper Protection off, GPO/registry, exclusions applied)
- Disabled Windows Search/Indexing
- Full node reboots after each change
- Fresh empty
G:\\dockerdirectory (renamed previous one to.bak) - BuildKit disabled (
features.buildkit=false) DOCKER_TMPDIRset to SSD and NVMe (both worked fine → NVMe usable outside windowsfilter)- Checked open handles with Sysinternals
handle.exe→ only dockerd DB files, no external locks - Checked
Containers-WcifsandBindFltlogs → no SHARING VIOLATION entries - Verified NTFS 4K cluster size (
Bytes Per Cluster = 4096)
Workarounds:
- Place
data-rooton SSD → builds succeed. - Use NVMe only for:
DOCKER_TMPDIR(build temporary files)- Bind mounts / cache directories
- Optionally:
mklink /J G:\\docker C:\\docker-data - ⚠️ Offloading builds to Linux BuildKit does not work for Windows-native images (e.g.,
servercore,nanoserver).
Impact:
- Blocks Windows container builds on nodes with NVMe-only storage.
- CI/CD pipelines cannot run
docker buildlocally with dockerd HostProcess ifdata-rootis NVMe. - Forces SSD allocation for data-root, which reduces performance and complicates infrastructure design.
- Dominant language
- PowerShell
- Stars
- 551
- Forks
- 76
- PR merge metrics
- No merged PRs in 30d
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from microsoft/Windows-Containers
-
enhancement triage
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
microsoft/Windows-Containers#630 · 5 comments ·
-
bug triage
Difficulty 3/5 1-2 days Newbie friendliness 55/100
microsoft/Windows-Containers#648 · 2 comments ·
-
Difficulty 5/5 Over a week Newbie friendliness 30/100
microsoft/Windows-Containers#647 · 3 comments ·
-
Difficulty 5/5 Over a week Newbie friendliness 35/100
microsoft/Windows-Containers#646 · 2 comments · 1 reaction ·
-
bug triage
Difficulty 4/5 3-5 days Newbie friendliness 48/100
microsoft/Windows-Containers#645 · 4 comments ·
All issues in microsoft/Windows-Containers
Similar issues
-
Difficulty 2/5 1-3 hours Newbie friendliness 84/100
copse-dev/agent-pane#2953 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 90/100
simonw/sqlite-utils#872 ·
-
Difficulty 1/5 Under an hour Newbie friendliness 84/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 84/100
danielmiessler/LifeOS#2215 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
sympozium-ai/sympozium#627 ·