I’m running Docker Desktop on Windows 11 with WSL2 backend. My setup is specific because I migrated all Docker data to a dedicated 128GB SSD (D: drive).
8 containers all running, all data mounted as external volumes on D: and E:
Total Docker data declared by docker system df : ~12.4 GB
Actual VHDX size : ~15.9 GB
Problem : Every time Docker Desktop updates (which happens almost every week), the VHDX file grows by approximately 1.5 GB permanently. Since I have a 128GB SSD dedicated to Docker, this will fill up very quickly.
What I already tried without success :
docker system prune -a --volumes → 0B reclaimed (all containers active)
diskpart compact vdisk → no change in VHDX size
fstrim via justincormack/nsenter1 → reported 990GB trimmed (virtual size) but VHDX unchanged
wsl --manage docker-desktop --set-sparse true → blocked by Microsoft (unsafe flag required)
Sparse mode not available without --allow-unsafe flag
Question : What is the correct procedure to reclaim space lost after each Docker Desktop update, specifically with a migrated VHDX on a secondary drive and only the docker-desktop distro (no docker-desktop-data) ?
I’m not sure why the data disk grows when the Desktop gets an update. It has its own disk. Maybe there is an upgrade proces that changes docker agent data like its own databases.
My guess is that your problem is that Docker Desktop cannot handle directly how filesystem is written and it is written randomly on the whole available disk. Since WSL will create a huge virtual disk (maybe the size of your phyisical disk? I don’t remember) it can make the disk bigger every time it writes a new sector.
We noticed it with Docker Sandbox on new MacBooks first where the disk is also SSD.
There is also a link to an issue on Github in the topic, but not really active and that is for Docker Sandbox which uses microVMs. I don’t know how it could be fixed in WSL. Until there is a better way, you can check if this works for you
The difference compared to what you tried is likely that you ran fstrim, but didn’t trim the disk itself. The sparse flag would only mean that the newly created disks are created as sparse files, but that wouldn’t help and I don’t understand why the WSL documentation says sparse is not the default. As far as I know, it just means a 1TB disk will not phisically be 1TB on the host and only uses as much space as it is used inside the virtual disk on the filesystem. That is how it works now for you anyway if I understand it correctly.
docker system prune -a --volumes → 0 bytes recovered
diskpart + VHDX compaction → no change
fstrim via justincormack/nsenter1 → shows a virtual reduction, but the actual size of the VHDX remains unchanged
wsl --manage docker-desktop --set-sparse true → blocked by Microsoft (requires --allow-unsafe)
My specific configuration:
VHDX moved to a secondary SSD (D:\mydocker\DockerDesktopWSL\disk\docker_data.vhdx)
Only the docker-desktop distribution exists (no docker-desktop-data)
All containers use external volumes mounted on D: or E:
What I’m looking for:
A safe and reproducible method to reclaim space after every Docker Desktop update, without having to completely reset WSL2.
I’ve seen people mention Optimize-VHD (PowerShell) by stopping Docker Desktop, mounting the VHDX, optimizing it, and then unmounting it. Does this work on a VHDX currently in use by WSL2?
I would be surprised if it does. You might want to close Docker Desktop and execute wsl --shutdown to terminate all running distributions and the wsl system vm before shrink the vhdx.
It’s been a while since Docker Desktop for Windows stopped using the docker-desktop-data distribution. Since then, it’s an additional vhdx file that gets attached and mounted in the docker-desktop distribution.
I wanted to give an update on the issue I opened. Thanks to other users, we have identified the exact cause of the VHDX growth problem. Docker Desktop is permanently keeping all historical versions of its internal ISO files inside /mnt/docker-desktop-disk/isocache/entries.
I have proposed a simple fix on the related GitHub ticket (#375): modify the update script to keep only the latest (or latest two) versions of these ISOs.
Quick follow-up on my previous post (May 24). Since identifying the root cause (stale ISOs in /mnt/docker-desktop-disk/isocache/entries) and linking to GitHub issue #375, there’s been no official word from Docker yet, and the VHDX continues to grow after each update on my machine (Docker Desktop 4.71).
I’ve also opened a suggestion (#419) to keep only the latest ISO versions during updates.
Has anyone discovered a safe, non-destructive workaround that doesn’t require a full WSL2/Docker reset? I’d rather not manually delete the isocache entries without official guidance. Any hint would be appreciated.
I have no new information, but I could also confirm it today, so I asked about it internally sharing the github issue with the developers.
I also checked it on macOS, and I found no isocache yet. but there is a folder called /oldroot which is 625MB. I assume that is the equivalent of the isocache, but on Mac, it keeps only the previous version.
I will also keep asking about it unti there is a response either internally or on GitHub.