Where does Docker keep images/containers so i can better track my disk usage

It would be cool to have the amount of disk being used by the VM in the D4M app to help make keeping track of disk space easier.


Has anyone come up with a solution to reduce the size over time? I’m now over 40G. If I remove images the size doesn’t seem to be reduced at all.

1 Like

After creating and removing many images my Docker.qcow2 becomes very large. I found a solution how to shrink it. It creates new image based on the old and reduces unused space. This works for me:

cd ~/Library/Containers/com.docker.docker/Data/com.docker.driver.amd64-linux
/Applications/Docker.app/Contents/MacOS/qemu-img convert -O qcow2 Docker.qcow2 Docker2.qcow2
mv Docker2.qcow2 Docker.qcow

There is also “-c” switch which adds compression to the image but my docker daemon is not able to run with it.


Is that supposed to be mv Docker2.qcow2 Docker.qcow2

1 Like

I’ve seen several janitor container that cleanup periodically.


As I a build stuff, run compose, etc I run several commands to clean up…

 # remove untagged images  
 docker rmi $(docker images | grep none | awk '{ print $3}')
 # remove unused volumes  
 docker volume rm $(docker volume ls -q )  
 # `shotgun` remove unused networks
 docker network rm $(docker network ls | grep "_default")   
 # remove stopped + exited containers, I skip Exit 0 as I have old scripts using data containers.
 docker rm -v $(docker ps -a | grep "Exit [1-255]" | awk '{ print $1 }')

This worked. I can only expect this is not the solution going forward.

Thanks for the report. Yes we’re aware that disk usage isn’t exactly transparent right now.
We’re working on several improvements in this area to help better manage the diskspace used by the VM. If you find that the image has grown too big and you aren’t worried about any of the images stored you can safely delete the QCOW2 file and restart Docker for Mac. This is only a temporary solution though - watch out for improvements in the changelog soon


I was only able to get Docker to stand back up if I do the following:

  1. Quit via menu
  2. rm ~/Library/Containers/com.docker.docker/Data/com.docker.driver.amd64-linux/Docker.qcow2
  3. Start via Finder

Else it seems to hang on startup; submitted another ticket, search for “Busy Whale”.


A mitigation for people with not much free space on their drives is to symlink the Docker.qcow2 file to an external drive.


Although qemu-img command can shrink the Docker.qcow2 file size, but not help too much. Because after removing docker image files, the unused garbage images still remain in the ext4 file system under Docker.qcow2, and these garbage contents resided in ext4 file system cannot be swept away merely executing qemu-img command.

To clean the garbage, one should tend to fill zero bytes in the free space of ext4 file system, and only then could Docker.qcow2 be reduced by qemu-img command.

So there are several extra steps to reduce Docker.qcow2 should be done under Linux system, briefly discussed below:

  1. screen ~/Library/Containers/com.docker.docker/Data/com.docker.driver.amd64-linux/tty to access docker host
  2. login as root
  3. dd if=/dev/zero of=/mnt/docker/zero bs=4096 to fill zero bytes into the free space of the ext4 file system under Docker.qcow4, until the disk is full
  4. rm /mnt/docker/zero then all the free space of Docker.qcow2 would be filled by zero bytes
  5. logout, and detach screen

After above steps manipulated in docker host, Docker.qcow2 can then be reduced by executing:
/Applications/Docker.app/Contents/MacOS/qemu-img convert -O qcow2 Docker.qcow2 Docker2.qcow2

BTW, I think it is too cumbersome to do such file reducing processes, and I have an suggestion for implementing storage management in future versions. I suggest that the files (aka aufs images) in /var/lib/docker had better not be placed under Docker.qcow2 disk image, since it is too varying when adding/removing files frequently, and it is too easy to produce non-zero garbage contents in ext4 file system which cannot be swept away by qemu-img command. Instead, these files may be placed under Mac OS X native file system, then establish file accesses in OS X file system when accessing /var/lib/docker in docker host. This simplifies the storage management, and users can direct see how the docker files act, similar to those in Linux system


This Docker.qcow2 file is indeed scary. Mine had 60GB, so I just followed the instructions here and closed Docker, deleted the file and opened Docker again. Its size was stable at 1.1GB after I opened Docker. I went away from computer for a few minutes, Mac OS X locked from inactivity and when I’m back, the file was increasing in size again pretty fast - it’s already at 17GB and I’m still doing absolutely nothing. Is this a bug?

My solution was to put that Docker.qcow2 on other non-ssd drive and link to it:

mv ~/Library/Containers/com.docker.docker/Data/com.docker.driver.amd64-linux/Docker.qcow2 /LargeDrive/Docker/Docker.qcow2  
ln -s /LargeDrive/Docker/Docker.qcow2  ~/Library/Containers/com.docker.docker/Data/com.docker.driver.amd64-linux/Docker.qcow2

so now I don’t care how big it grows… however, having an elegant way to maintain the file would be neat.

Issue has made Docker unusable. Simply starting the docker app, no containers running, and Docker.qcow2 grows by about 2MB/sec, fills the disk rapidly.

@kaellis that is a different issue that was fixed with Beta 13.1 hotfix on Saturday. Please update your installation and check the disk usage, again.

Maybe it wasn’t actually fixed, not sure. I stopped Docker, removed the Docker.qcow2 file (which was 56G before!), restarted Docker (beta13.1 build 8193), and after a couple of minutes the file has grown to 1.1G. “docker images” shows nothing. There’s clearly no reason for a 1GB file when Docker isn’t actually doing anything yet…although it seems to have stopped at 1.1G and isn’t growing any more. It’s better than 56G but still…

The qcow file is a block disk image that grows when unwritten blocks in the 64GB virtual device are written so the sparsity of writes due to ext4 disk layout causes an initially large increase in image size. We are investigating alternatives to the block device but they are not ready yet. In conclusion, while the behavior you observe, @masonck, is not ideal it is working as intended.

Thanks for participating in the Docker for Mac Beta!

1 Like

Good to know, thanks for the update and info. That makes sense, even if it’s not ideal. Good luck with the research. Hopefully 13.1 will keep it below 56G now! That plus an out-of-control log file (39G) made for some issues but were easy to clean up and restart and otherwise Docker for Mac has been great. Thanks.

Mine is at 72GB, and qemu-img convert managed to create a 60GB file before dying due to lack of disk space :unamused:

What do I lose by deleting Docker.qcow2 ?

While using a single container to convert a 15second mp4 to a gif (using the screengif docker image) my Docker.qcow2 file kept growing. I had to kill it at 9.8GB before running out of diskspace.

I’ve removed the container, image, volumes, etc. Disk usage is still 9.8GB. I’ve had to remove the file to make my system responsive again. (I’m on an older 2011 MacBook Air with 128GB disk).

Any progress on this? Docker-for-Mac is unusable for me like this.

Having the same issue. The qcow2 file inexplicably becomes enormous until I run out of disk space. Around 20gb in my case.