Docker: no space left on device

Fix Docker "no space left on device": run docker system df, then docker system prune and docker builder prune. Covers container logs, volumes and Desktop.

easy fix·7 min read

By Vishvesh Patel·DevOps Engineer·Updated 16 September 2026

Run these in order. Each one tells you what its output means before you change anything.

• See what is actually using the space

RECLAIMABLE is what you get back for nothing. Build Cache or Images in double-digit gigabytes is the usual answer, and is entirely safe to remove.

• Reclaim the safe things first

Build cache is nearly always the biggest safe win and nothing running depends on it. Run docker system df again before going further.

• If that is not enough, drop unused images

This removes every image no container is using. Stop here and check docker volume ls before pruning volumes. Those hold data, and the deletion is not recoverable.

• If Docker looks clean but writes still fail, check the host

A full host disk or exhausted inodes looks identical from Docker's side. Runaway container logs are the usual cause. Check /var/lib/docker/containers.

Docker has filled its storage location, usually /var/lib/docker, with image layers, stopped containers, build cache, volumes and logs that nothing cleaned up.

The useful question is not "how do I free space" but which of those five is actually responsible, because the fix differs and one of them is invisible to docker system prune.

Always start here rather than pruning blindly:

-v breaks it down per object, which tells you exactly which volume or image is the problem:

And check whether Docker is even the culprit:

That third line is the one people miss.

This removes all stopped containers, all unused images, all unused networks, all build cache and all volumes not attached to a container.

Be careful with --volumes. It deletes data. A database volume whose container is stopped counts as unused and will go, permanently. Run docker volume ls first and confirm you recognise everything on the list.

The safer incremental version:

Build cache is almost always the safest large reclaim. It regenerates automatically and the only cost is a slower next build.

If pruning freed far less than docker system df suggested, this is why.

docker system prune never touches container logs. A long-running container using the default json-file driver with no rotation writes unbounded output:

A single chatty container reaching tens of gigabytes is entirely normal after a few months.

Truncate one immediately:

Then stop it recurring, which is the part that matters. Set a global default in /etc/docker/daemon.json:

This applies to newly created containers only. Existing ones keep their original configuration until recreated.

Volumes are excluded from the default prune deliberately, because they hold data. They also accumulate invisibly:

The usual culprit is anonymous volumes. An image declaring VOLUME /data, most database images do, creates a fresh unnamed volume on every docker run where you did not mount one. Start a Postgres container twenty times while testing and you have twenty volumes holding real data.

Prevent it by always mounting a named volume explicitly, and using --rm on throwaway runs, which removes anonymous volumes on exit.

An awkward state: the daemon cannot start, so docker commands do not work either.

If Docker still will not start, deleting build cache directly is a last resort, but never delete overlay2 subdirectories by hand. That corrupts the image store, and the recovery is stopping the daemon and removing /var/lib/docker entirely, which destroys every image, container and volume on the host.

On macOS and Windows, Docker stores everything inside a virtual disk image. Deleting containers does not shrink that file. It grows to a high-water mark and stays there.

Prune inside Docker as normal, then reclaim the host space in Docker Desktop → Settings → Resources → Disk image size, or use the troubleshoot panel's clean-up. Simply raising the allocated size buys time without addressing the cause.

A weekly cron job covers most of it:

The until filter keeps anything used in the last week, which makes this safe to automate in a way that a bare prune -a is not.

How do I fix "no space left on device" in Docker?

Start with docker system df to see which category is consuming space rather than pruning blindly. Then reclaim in increasing order of risk: docker builder prune for build cache, which is the safest large win, then docker image prune -a and docker container prune, and only finally docker volume prune after checking docker volume ls, since that one deletes data. If pruning frees far less than expected, the space is almost certainly in container logs, which prune never touches.

Why did docker system prune not free up space?

Because it does not touch container logs. With the default json-file driver and no rotation configured, a long-running container writes unbounded output to /var/lib/docker/containers/<id>/<id>-json.log, and tens of gigabytes from a single chatty container is common. Check with sudo du -sh /var/lib/docker/containers/* | sort -rh. Truncate the offender, then set max-size and max-file in /etc/docker/daemon.json so it cannot recur. Volumes are the other exclusion, requiring --volumes explicitly.

Is docker system prune -a --volumes safe to run?

Not without checking. It removes every stopped container, every unused image, all build cache and every volume not currently attached to a container, and that last part deletes data permanently. A database volume whose container happens to be stopped counts as unused. Run docker volume ls first and confirm you recognise everything. Without --volumes the command is much safer, since the worst outcome is re-pulling images and a slower next build.

What is taking up space in /var/lib/docker?

Run sudo du -sh /var/lib/docker/* | sort -rh to see. overlay2 holds image and container layers and is usually the largest, addressed by pruning images. volumes holds persistent data, which prune skips by default. containers holds the logs, which prune never removes and which are the most common cause of space that pruning fails to reclaim. Never delete anything under overlay2 by hand. It corrupts the image store.

How do I stop Docker filling the disk again?

Cap the logs first, by setting "log-opts": {"max-size": "10m", "max-file": "3"} in /etc/docker/daemon.json and restarting Docker. Note this applies only to newly created containers. Add --rm to one-off runs so nothing accumulates. Always mount named volumes explicitly rather than letting images create anonymous ones. Then schedule a weekly docker system prune -af --filter "until=168h", which keeps anything used in the last week and is safe to automate.

Why does deleting Docker images not free space on macOS?

Because Docker Desktop stores everything inside a single virtual disk image, and that file grows to a high-water mark without shrinking when you delete things inside it. Pruning frees space within the VM but the host file stays the same size. Reclaim it through Docker Desktop's Settings under Resources, where you can shrink or reset the disk image, or via the clean-up option in the troubleshoot panel. Increasing the allocated size instead only postpones the problem.

Free, comprehensive DevOps tutorials and learning roadmaps. Master Docker, Kubernetes, CI/CD, and more.

Get notified about new tutorials and features.

• Roadmaps

• Interview Prep

• Certifications

• Company

© 2026 DevOpsLesson. All rights reserved.