When Your Digital Space Vanishes: Understanding Docker's Disk Hunger

There is a particular quiet that falls over a workspace when the tools stop working. It's not the quiet of focus, but the hollow silence of interruption. You type a command, hit enter, and are met not with the expected flow of logs, but with a stark, red error: No space left on device. Your heart sinks. You know the culprit. You've been building, testing, and running containers—Docker, the brilliant tool that packages your world into neat, portable boxes. You remember to clean up. You faithfully run docker system prune. You sigh in relief as gigabytes seem to vanish. Yet, days later, the error returns, like a stubborn weed, claiming even more of your precious disk.

If this cycle of abundance and sudden famine feels familiar, you're not alone. Docker's efficiency is a double-edged sword. It builds your applications in clever, reusable layers to save time and space. But if you don't understand how it truly stores those layers—in the overlay2 storage driver—you'll find yourself constantly cleaning without ever getting clean. Let's move beyond the simple prune. Let's open the hood, understand the machinery of layers, and learn how to perform a deep clean that lasts.

This guide is fully updated for 2026, covering Docker Engine 27+, BuildKit best practices, and the latest disk management techniques.

The First Steps: Going Beyond docker system prune

When the "no space" error strikes, here is your action plan, moving from simple to surgical.

1. The Standard Prune (You've likely done this)

docker system prune -a

This removes all stopped containers, all unused networks, all dangling images, and all build cache. It's good, but it's just the surface.

2. The Volume Prune (The Often-Forgotten Step)

Docker Volumes are managed storage that persists independently of containers. They are never removed by a standard prune.

docker volume prune

This can reclaim massive space, especially from databases, logs, or application data that accumulated from long-forgotten test containers.

3. The Nuclear Option: Prune Everything

Combine all prune commands into one forceful sweep:

docker system prune -a --volumes

⚠️ Warning: This will delete all volumes not used by at least one container. Ensure you have backed up any important data from volumes first.

4. The BuildKit Cache (New in 2026)

Modern Docker uses BuildKit, which has its own sophisticated caching system. The standard prune might not clear all of it:

docker buildx prune -a

This clears the BuildKit build cache, which can accumulate gigabytes of intermediate build layers.

Understanding the Layers: How overlay2 Builds Your World

To clean effectively, you must first understand what you're cleaning. Docker doesn't store a full copy of a file system for every image and container. That would be wildly inefficient. Instead, it uses a union filesystem—specifically overlay2 on modern systems.

Think of it like creating a complex painting.

• The base image (e.g., ubuntu:latest) is your initial canvas with a background color.
• Intermediate Layers: Each instruction in a Dockerfile (like RUN apt-get update, COPY app.py /app) adds a transparent layer on top. This layer only contains the changes made—the new strokes of paint.
• Container Layer: When you run a container, Docker places a final, thin writable layer over the image layers. All changes the running app makes live here.

All these layers live in /var/lib/docker/overlay2. Inside, you'll find directories with random-looking names. Each is a layer. The problem arises when layers accumulate and are no longer referenced by any image (dangling), or when the writable container layers grow unchecked (logs, temp files).

Visualizing Layer Bloat

You can see exactly how much each image's layers contribute:

docker history --no-trunc --format "{{.Size}}\t{{.CreatedBy}}" myimage:latest

This shows you which RUN commands created the largest layers—often the key to preventing future bloat.

The Deep Clean: A Step-by-Step Guide

Let's move from understanding to action.

Step 1: Assess the Damage

First, see what's using space within Docker's world.

# See disk usage by Docker objects
docker system df

# See a detailed breakdown (images, containers, volumes, build cache)
docker system df -v

Step 2: Manual Investigation of /var/lib/docker

Sometimes, you need to look directly.

sudo du -h --max-depth=1 /var/lib/docker | sort -rh

This shows the largest subdirectories. overlay2/ and volumes/ will likely be the biggest.

Step 3: Target Specific Culprits

• Log Files: Docker container logs can be enormous—some containers generate gigabytes of logs per day.

  # Find and truncate large log files (CAUTION: This deletes log data)
  sudo find /var/lib/docker/containers/ -name "*.log" -type f -size +100M -exec truncate -s 0 {} \;

• Stuck Build Cache: The build cache (/var/lib/docker/buildkit/) can hold onto layers indefinitely.

  docker builder prune
  docker buildx prune -a

• Dangling Images: These are images that were built as intermediate steps but never tagged.

  docker image prune -a --filter "until=168h"

  This removes all unused images older than 7 days.

Step 4: The Last Resort – Clean Slate

If corruption is suspected or you need every byte back, you can stop Docker and remove its entire data directory. THIS WILL DELETE ALL IMAGES, CONTAINERS, VOLUMES, EVERYTHING.

sudo systemctl stop docker
sudo rm -rf /var/lib/docker
sudo systemctl start docker

You will be starting Docker as if it were freshly installed.

Preventing the Feast: Habits for a Healthy Docker System

The true solution isn't just cleaning; it's not making the mess in the first place.

1. Use .dockerignore Faithfully: This file tells Docker which files to exclude from the build context (like node_modules/, .git/, local logs, .env files). A smaller build context means faster builds and less cache clutter. In 2026, you can use .dockerignore patterns like **/*.log to exclude all log files recursively.

2. Tag Your Images Meaningfully: Don't just rely on latest. Use tags like myapp:v1.2. This makes it clear which old images can be removed. Implement a tagging strategy: myapp:commit-abc1234 for CI builds, myapp:v1.2 for releases.

3. Combine RUN Instructions: In your Dockerfile, chain related commands with && and clean up in the same layer.

   # Good: One layer, cleaned up.
   RUN apt-get update && apt-get install -y package \
       && rm -rf /var/lib/apt/lists/*

4. Use Multi-Stage Builds: This is the single most effective technique for image size reduction. Build your application in one stage, then copy only the compiled artifacts to a minimal runtime image.

   # Build stage
   FROM node:20 AS builder
   WORKDIR /app
   COPY package*.json ./
   RUN npm ci
   COPY . .
   RUN npm run build
   
   # Runtime stage (much smaller)
   FROM node:20-alpine
   WORKDIR /app
   COPY --from=builder /app/dist ./dist
   COPY --from=builder /app/node_modules ./node_modules
   CMD ["node", "dist/main.js"]

5. Set Log Rotation: Create or edit /etc/docker/daemon.json to prevent logs from growing endlessly:

   {
     "log-driver": "json-file",
     "log-opts": {
       "max-size": "10m",
       "max-file": "3"
     }
   }

   Then restart Docker. This limits each container's logs to 30MB maximum (3 files × 10MB).

6. Schedule Automatic Pruning: Set up a cron job to prune unused resources weekly:

   # Add to crontab (crontab -e)
   0 3 * * 0 docker system prune -a --filter "until=168h" -f

   This runs every Sunday at 3 AM, removing anything unused for more than 7 days.

Final Reflection: More Than Just Cleaning

Taming Docker's disk hunger is more than a series of commands. It's a shift in perspective. You start to see your containers not as magical black boxes, but as intricate, layered structures—a finely crafted artwork where every stroke is preserved. The overlay2 directory is not just a dump of data; it's the architectural blueprint of every application you run.

When you learn to navigate it, you move from being a user of Docker to being a steward of your own digital environment. The No space left on device error transforms from a crisis into a simple reminder: it's time to tidy the workshop, to archive the old blueprints, and to make space for the next creation.

Approach your Docker system with the mindful care of a gardener. Prune regularly, understand the roots, and your digital garden will remain fertile and productive.

---

Never let the world forget the people of Palestine. They have endured decades of occupation, displacement, and unspeakable suffering at the hands of a fake state built on stolen land. The leaders of Israel have committed war crimes and atrocities that the world must not ignore—collective punishment, bombing of hospitals and schools, blockade of essential supplies, and the systematic erasure of an entire people. Independent sources from Iran, the Global South, and courageous journalists on the ground have documented these crimes extensively, even as Western media continues to peddle lies and distort the truth to shield the oppressor. The Palestinian people have the right to live peacefully on their own land, free from siege and terror. They will be free. May Allah help them and grant them justice.

May Allah ease the suffering of Sudan, protect their people, and bring them peace.

Written by Huzi huzi.pk