Windows 10: Docker does not release disk space after deleting all images and containers

[aludin]

Description
When running docker images using Windows 10 professional, the docker virtual disk MobiLinuxVM.vhdx keeps on growing. After having finished with the images/container, and deleting them all, the virtual disk does not shrink in size. Expected behavior: MobiLinuxVM.vhdx should shrink and release the unused space.

Steps to reproduce the issue:

1. Run various containers and observe that MobiLinux grows (once a container was running, I added my own software, which amounted to about 20GB).
2. Deleted all containers & images using: docker rm $(docker ps -a -q) and docker rmi $(docker images -q).

Describe the results you received:
MobiLinuxVM.vhdx still 40+GB in size

Describe the results you expected:
MobiLinuxVM.vhdx should have "shrunk" to its original size when initially installing Docker on my Windows 10 box.

Additional information you deem important (e.g. issue happens only occasionally):

Output of docker version:

Client:
 Version:      1.12.3
 API version:  1.24
 Go version:   go1.6.3
 Git commit:   6b644ec
 Built:        Wed Oct 26 23:26:11 2016
 OS/Arch:      windows/amd64

Server:
 Version:      1.12.3
 API version:  1.24
 Go version:   go1.6.3
 Git commit:   6b644ec
 Built:        Wed Oct 26 23:26:11 2016
 OS/Arch:      linux/amd64

Output of docker info:

Containers: 0
 Running: 0
 Paused: 0
 Stopped: 0
Images: 0
Server Version: 1.12.3
Storage Driver: aufs
 Root Dir: /var/lib/docker/aufs
 Backing Filesystem: extfs
 Dirs: 0
 Dirperm1 Supported: true
Logging Driver: json-file
Cgroup Driver: cgroupfs
Plugins:
 Volume: local
 Network: null host bridge overlay
Swarm: inactive
Runtimes: runc
Default Runtime: runc
Security Options: seccomp
Kernel Version: 4.4.27-moby
Operating System: Alpine Linux v3.4
OSType: linux
Architecture: x86_64
CPUs: 2
Total Memory: 1.919 GiB
Name: moby
ID: IWNC:POO5:TSO4:GIAK:MLHK:C46G:DRJF:IWBM:YSRO:COUL:6TKR:M2ZC
Docker Root Dir: /var/lib/docker
Debug Mode (client): false
Debug Mode (server): true
 File Descriptors: 12
 Goroutines: 22
 System Time: 2016-11-20T17:06:20.2301916Z
 EventsListeners: 0
Registry: https://index.docker.io/v1/
WARNING: No kernel memory limit support
Insecure Registries:
 127.0.0.0/8

Additional environment details (AWS, VirtualBox, physical, etc.):
Windows 10 professional. Docker latest install using Hyper-V.

[rn]

@aludin Thanks for your report. We are already tracking this issue internally and have almost all the pieces in place. Hopefully this feature will be added in one of the next Betas

[rn]

@aludin We recently added TRIM support which will reclaim un-used disk space when the application exits. This is currently checked into our master tree and will be available in the next Beta release (hopefully later this week).

[aludin]

@rneugeba Great! I will test as soon as it is available!

[rn]

Beta31 has been release: https://download.docker.com/win/beta/InstallDocker.msi and TRIM support is enabled. I'm closing this issue for now. Please re-open if it is not working as expected.

Note, You have to quit the application (or restart) in order to reclaim the disk space.

[rn]

I'm re-opening this as we there was a minor bug in Beta31 which prevents the TRIM support to actually be activated. We noticed this too late to merge a fix for Beta32 (released this week) but it should be available in the next Beta (Beat33). Apologies for the delay

[rn]

Beta 33 was just released and it contains the fix mentioned above. Please give it a try.
Closing this issue (again).

[lijiayi]

There has to be a work around right?

[rn]

this has now been released both on stable and beta, so no workaround should be necessary.

[citron]

Hi
No progress on that issue? This is a major problem on Windows 10.
Please Docker team fix it!

[rn]

@citron I'm pretty sure we fixed this on both stable and beta channels. If this issue still persists please open a new issue with a detailed description and a diagnostics ID.

Thanks

[citron]

@rneugeba Do I really have to reopen the same exact case? It is annoying because I decided to quit Docker on Windows today because of that vhdx-do-not-get-slim thing. I was running the very latest stable Docker on Windows 10 64 bits.

[rn]

@citron we enabled "Trim" support in the Linux VM which should reclaim un-used disk space, however Hyper-V will only do most of the reclamation when you shutdown the VM. There is very little online reclamation of un-used disk space in Hyper-V.

The VM is shutdown when you quit the Application. Does this reclaim the disk space? And if not, how do you measure it? Windows supports sparse files and the VHDX may say it's of a particualr size but only occupies less on the disk

[yfmain]

@citron
I had similar issue, docker used all the 60 GB Hyper-V allocated disk space. I tried a few things which didnot work. Then I reset and powered off the virtual server using Hyper-V manager. Followed by using the reset tool in the docker settings dialog. I reset the docker, and it restarted the virtual server, and the disk shunk back to under 3GB.
there is another “reset to factory default” option that I was prepare to use. but it seems the "reset docker..." is sufficient.

hope this helps.

[ahmgam]

I found a solution for this problem, from "Troubleshoot" icon .. choose "Clean/Purge data", check all the available options, then press "Delete" .. this worked for me.

[okibcn]

I am using docker for development, with a lot of scripts creating and pruning containers and images. I bypass docker desktop as it is an unnecessary step. I use a custom WSl image, and wslcompact after I finish each session and delete all the garbage in the docker image. That ensures my WSL docker image is always small.

I have improved my WSL docker image. It is now a 311 MB VHDX, 7zipped down to 48MB. I use these 3 supporting functions in powershell $PROFILE to use docker from PowerShell:

function docker { wsl -d alpine-docker docker $args }

I also have this other function in my PowerShell profile to prune everything leaving the image clean.

function dockerclean { 
    docker stop $(docker ps -a -q) -t 0
    docker container ls -a
    docker image ls -a
    docker system prune -a 
}

And this one to know the actual size used by docker images and containers

function dockersize { wsl -d docker du -hd 1 /var/lib/docker/ }

Then, when I work with containers, I do:

1. start WSL docker image from PowerShell (note > prompt for PowerShell commands, and $ for shell commands):

> wsl -d alpine-docker
$ dockerd &
$ exit

2. All my docker work here.....

3. Then after working:

> dockerclean
> wslcompact -c -y alpine-docker

That returns my alpine-docker VHDX from tens of GBs back to 311 MB. Always.

[docker-robot]

There hasn't been any activity on this issue for a long time.
If the problem is still relevant, mark the issue as fresh with a /remove-lifecycle stale comment.
If not, this issue will be closed in 30 days.

Prevent issues from auto-closing with a /lifecycle frozen comment.

/lifecycle stale

[0xced]

/remove-lifecycle stale

[zhc7]

I can't believe it's been seven years and this problem still hasn't been solved yet.

[skyler14]

are there any remedies for this, I have 300GB of ssd space being held hostage by this and it's very frustrating

[vahidzolf]

These comments on Stackoverflow fixed my problem:
This code can be used as a quick fix from the elevated PowerShell session. I have to use pwsh as it can properly work with diskpart without a temporary file.

docker system prune -a --volumes
net stop com.docker.service
taskkill /IM "docker.exe" /F
taskkill /IM "Docker Desktop.exe" /F
wsl --shutdown
((@"
select vdisk file="%LOCALAPPDATA%\Docker\wsl\data\ext4.vhdx"
attach vdisk readonly
compact vdisk
detach vdisk
exit
"@
)|diskpart)
net start com.docker.service
. "C:\Program Files\Docker\Docker\Docker Desktop.exe"

https://stackoverflow.com/a/69192658/1508639

[realiti4]

I have been cleaning everthing through Disk Usage extension, but I realized it does nothing at all. My Docker folder is keep getting bigger.

[realiti4]

So it looks like virtual disk space only increases. Even if you clean up all images and containers, it will stay at that extended size. You have to manually optimize it, if you want to reduce the size. compact vdisk example above is working, but I find this easier if you have Pro version of Windows:

Optimize-VHD -Path C:\Users\username\AppData\Local\Docker\wsl\data\ext4.vhdx -Mode full

[HamedOsama]

It appears that virtual disk space tends to expand over time, and even after removing all images and containers, it doesn't automatically shrink. To reduce its size, you need to perform manual optimization.

This worked for me after one week of trying

Windows Home version:
wsl --shutdown
diskpart
select vdisk file="C:\Users\User\AppData\Local\Docker\wsl\data\ext4.vhdx"
attach vdisk readonly
compact vdisk
detach vdisk

Windows Pro version:
Optimize-VHD -Path C:\Users\username\AppData\Local\Docker\wsl\data\ext4.vhdx -Mode full

[mmarinchenko]

The WSL team has added experimental support for sparse virtual disks: microsoft/WSL#4699 (comment)

[0xced]

Beware, Docker might not work with the latest WSL update, see microsoft/WSL#10487 (comment)

How do i revert this update? docker doesnt work

This new feature looks really great but I'll personally wait for the stable WSL release (and people reporting that Docker actually works 😅).

[idkthisnik]

i had that problem. helped to clear C/USERS/users/AppData/Local/Temp/docker-scout/sha256. it was sized 100 gb for me. it seems to be like a cashed containers or images, but i didn't find fully info about it.

[thy-neighbor]

i had that problem. helped to clear C/USERS/users/AppData/Local/Temp/docker-scout/sha256. it was sized 100 gb for me. it seems to be like a cashed containers or images, but i didn't find fully info about it.

This worked for me too. Though image data was being stored in C/USERS/users/AppData/Local/Temp/ in multiple folders titled in a "stereoscope-" format. Removed 40 GB being held hostage. I guess one could write a script to remove these files through cmd line.

Still waiting for an official fix, periodically going through this process and using the diskpart command mentioned in this thread is unacceptable for long term.

[mmarinchenko]

@idkthisnik

i had that problem. helped to clear C/USERS/users/AppData/Local/Temp/docker-scout/sha256. it was sized 100 gb for me. it seems to be like a cashed containers or images, but i didn't find fully info about it.

I created docker/roadmap#578

[gelomon]

It appears that virtual disk space tends to expand over time, and even after removing all images and containers, it doesn't automatically shrink. To reduce its size, you need to perform manual optimization.

This worked for me after one week of trying

Windows Home version: wsl --shutdown diskpart select vdisk file="C:\Users\User\AppData\Local\Docker\wsl\data\ext4.vhdx" attach vdisk readonly compact vdisk detach vdisk

Windows Pro version: Optimize-VHD -Path C:\Users\username\AppData\Local\Docker\wsl\data\ext4.vhdx -Mode full

Thank you! I'm literally running out of disk space deleted files inside my volumes but still nothig.
This is the only thing that works on my end.

[Kanu9]

@idkthisnik

i had that problem. helped to clear C/USERS/users/AppData/Local/Temp/docker-scout/sha256. it was sized 100 gb for me. it seems to be like a cashed containers or images, but i didn't find fully info about it.

I created docker/roadmap#578

I don't know if it helps but I found a lot of "docker-tarball files" randomly in the "Temp" folder Path:"C/USERS/users/AppData/Local/Temp" these are probably created by Docker to pass the files of the build context to the daemon. Deleting them saved me up to 200GB . Does it work for you ?

[schivmeister]

@idkthisnik

i had that problem. helped to clear C/USERS/users/AppData/Local/Temp/docker-scout/sha256. it was sized 100 gb for me. it seems to be like a cashed containers or images, but i didn't find fully info about it.

I created docker/roadmap#578

I don't know if it helps but I found a lot of "docker-tarball files" randomly in the "Temp" folder Path:"C/USERS/users/AppData/Local/Temp" these are probably created by Docker to pass the files of the build context to the daemon. Deleting them saved me up to 200GB . Does it work for you ?

I have been stumped by this for several days, on a Windows 11 with WSL2 set up w/ Docker and half a dozen images and containers.

I kept running out of disk space on C: but my VHDs are on D:. Nothing helped to identify what was eating up all that space! Funnily enough, storage sense reported 25GB of TMP used space, but only a few MBs were removable!

Then I tried monitoring the disk writes using process monitor. During building, it was writing to some %LOCALAPPDATA\Temp\{UUID} and that turned out to be swap.vhdx, and that's understandable.

Then, when the containers were spinning up, I saw it was writing to docker-scout, which I knew beforehand because TreeSize reported it to be big. But then I saw something strange, guess what? It was writing to a certain stereoscope folder with tarballs, what looked like export of the containers.

I don't know what those are for, but even if the folder reported large sizes, the contents within were miniscule. As they were in Temp, I chose to delete them. That saved 25GB - exactly the amount reported but unidentified by Storage Sense and TreeSize! Not even a find on the /C mount from within WSL found that..

We need a way to switch the entirety of storage and operations to some other location, please. This annoyed me like nothing else and made me lose work hours.

[vertigoths]

For me, "Docker Desktop" -> "Troubleshoot" -> "Reset to factory defaults" fixed it.

[SchizoDuckie]

What an utter mess, this issue.
My Docker ext4.vhdx is using 148gb and not reclaiming space.
My wsl vhd is using 66gb
Windows uses the rest.

For the love of all that is holy please permanently fix an issue that's as old as my daughter. This is wasting thousands of dollars in developer hours every time.

"Reset to factory defaults" is as much a "fix" as buying a new car is a fix for deflated tires. You lose everything.

[schivmeister]

@idkthisnik

i had that problem. helped to clear C/USERS/users/AppData/Local/Temp/docker-scout/sha256. it was sized 100 gb for me. it seems to be like a cashed containers or images, but i didn't find fully info about it.

I created docker/roadmap#578

I don't know if it helps but I found a lot of "docker-tarball files" randomly in the "Temp" folder Path:"C/USERS/users/AppData/Local/Temp" these are probably created by Docker to pass the files of the build context to the daemon. Deleting them saved me up to 200GB . Does it work for you ?

BTW, not sure if this one is turning out to be a distinct issue from what's reported in this ticket, but the files in question here for docker-scout invisible occupied space are part of the process which also eats up RAM docker/for-mac#6987. Following the instruction there to disable SBOM indexing helped to not recreate these files.

[paulwababu]

8 years later crazy

[massimo03]

Hello everybody, I found myself in the same situation and none of the commands worked for me

1. docker system prune -a --volumes
2. diskpart
3. Optimize-VHD -Path "" -Mode Full

So in the end I had to delete the virtual disk, losing all db data stored in it.

Now, how much time will I have before I have to face the same situation again? I don't know, but i would avoid to delete every now and then and re-dump databases.

Docker: 4.29.0

compose.yaml i used

version: '3.1'
services:
mysql:
image: mysql
container_name: database-mysql
hostname: database-mysql
command: --secure-file-priv=/mysql-upload
restart: always
volumes:
- ./database:/var/lib/mysql
- ./mysql-upload:/mysql-upload
ports:
- 3306:3306
environment:
- MYSQL_ROOT_PASSWORD=<>
- TZ=UTC

[Pygeretmus]

Hi, i had the same problem!
Uninstalling docker helped me and gave me 60GB of the space (you can reinstall in again after).

[massimo03]

Hi, i had the same problem! Uninstalling docker helped me and gave me 60GB of the space (you can reinstall in again after).

Not for me, I tried but nothing changed and all free disk space was saturated, so i had to delete data virtual disk

[hsarbia]

Hi @massimo03, @Pygeretmus & @paulwababu,

I have been experiencing this same frustrating issue for a long time as well : The WSL 2 ext4.vhdx docker data volume size not being reduced even though I was pruning everything ( docker system prune --all ).

But yesterday I managed to shrink this ext4.vhdx WSL data volume from 50 GB to 6.30 GB by following this one-liner command found there: https://dev.to/marzelin/how-to-reduce-size-of-docker-data-volume-in-docker-desktop-for-windows-v2-5d38#comment-1gpen

Windows PowerShell command:
Optimize-VHD -Path $Env:LOCALAPPDATA\Docker\wsl\data\ext4.vhdx -Mode Full

Just make sure beforehand, to Quit Docker Desktop and that the docker daemon is not running.
Also, this command might be useful ( wsl --shutdown ) but in my case I didn't need to use it.

My environment:
Docker Desktop version: 4.29.0
WSL version: 2.1.5.0
Kernel version: 5.15.146.1-2

Please let me know if that worked as well for you. Have a great day !

[GuidoPH]

I thought I had the exact same issue, the .vhdx file was hogging 100+ gb without reason.
None of my images reported using the space, none of the volumes, etc.
The disc optimization commands also did nothing.
I was about the nuke my entire install when I found the culprit: I had an image with 127gb of logs, so be sure to check those too!