🎉 DevOps Interview Prep Bundle is live — 1000+ Q&A across 20 topicsGet it →
All Articles

Docker Build: No Space Left on Device — How to Fix It

Getting 'no space left on device' during docker build? Here's exactly what's eating your disk and the commands to fix it fast without losing your images.

DevOpsBoysMay 28, 20264 min read
Share:Tweet

You're in the middle of a build and Docker hits you with:

error: failed to solve: failed to read dockerfile: error from sender: 
write /tmp/docker-buildkit...: no space left on device

or

failed to create shim: OCI runtime create failed: container_linux.go:380: 
starting container process caused: process_linux.go: no space left on device

Your disk is full. Here's how to figure out what's using it and clean it up without nuking anything important.


Step 1: Find Out How Much Docker Is Using

bash
docker system df

Output looks like:

TYPE            TOTAL     ACTIVE    SIZE      RECLAIMABLE
Images          47        12        18.3GB    14.2GB (77%)
Containers      8         3         1.2GB     890MB (74%)
Local Volumes   15        6         4.5GB     2.1GB (46%)
Build Cache     -         -         6.8GB     6.8GB

This tells you exactly where the disk is going. In most cases, it's:

  1. Build cache — old build layers accumulating
  2. Images — pulled images you forgot about
  3. Stopped containers — exited containers still taking space
  4. Volumes — dangling volumes from deleted containers

Fix 1: Nuclear Option (When You're in a Hurry)

If you're in CI/CD or a dev machine where nothing important is running:

bash
docker system prune -a --volumes

Warning: This removes:

  • All stopped containers
  • All images not used by running containers
  • All volumes not used by running containers
  • All build cache

Frees up the most space. Use when you just need things to work NOW.


Fix 2: Safe Cleanup (Production/Shared Machines)

Do this step by step so you don't delete something you need.

Remove build cache first (safest)

bash
# Remove all build cache
docker builder prune
 
# Remove only cache older than 48 hours
docker builder prune --filter until=48h
 
# Check how much space it used
docker builder prune --dry-run

Build cache is usually the biggest culprit and 100% safe to delete — Docker just rebuilds it next time.

Remove dangling images

bash
# Dangling = untagged images (intermediate build layers)
docker image prune
 
# Check first
docker image prune --dry-run

Remove specific images you don't need

bash
# List all images with size
docker images --format "table {{.Repository}}\t{{.Tag}}\t{{.Size}}" | sort -k3 -h -r
 
# Remove specific image
docker rmi image-name:tag
 
# Remove all images with specific name pattern
docker images -q "myapp" | xargs docker rmi

Remove stopped containers

bash
# List stopped containers
docker ps -a --filter "status=exited"
 
# Remove them
docker container prune
 
# Or be selective
docker rm $(docker ps -aq --filter "status=exited")

Remove dangling volumes

bash
# List dangling volumes
docker volume ls -f dangling=true
 
# Remove them
docker volume prune
 
# Warning: volumes may contain database data!
# Check before deleting
docker volume inspect VOLUME_NAME

Fix 3: Change Docker's Storage Location

If you're running out of space on / but have another disk with more space:

Linux (Docker daemon config):

bash
# Edit daemon.json
sudo nano /etc/docker/daemon.json
json
{
  "data-root": "/mnt/data/docker"
}
bash
# Stop Docker, move data, restart
sudo systemctl stop docker
sudo mv /var/lib/docker /mnt/data/docker
sudo systemctl start docker

Verify:

bash
docker info | grep "Docker Root Dir"

Fix 4: BuildKit Cache Location

If you're using BuildKit (default in Docker 20+), it has its own cache location:

bash
# Check BuildKit cache
du -sh ~/.docker/buildx
 
# Clean it
docker buildx prune
 
# Or for a specific builder
docker buildx prune --builder mybuilder

Fix 5: Docker in CI/CD (GitHub Actions, GitLab CI)

In CI environments, runners often run out of space because every build pulls images fresh.

GitHub Actions:

yaml
- name: Free up disk space
  run: |
    docker system prune -f
    docker volume prune -f
 
- name: Build with BuildKit cache
  uses: docker/build-push-action@v5
  with:
    context: .
    push: true
    cache-from: type=gha
    cache-to: type=gha,mode=max

The cache-from: type=gha uses GitHub Actions cache to persist Docker layers between runs, reducing both build time AND disk usage.

GitLab CI:

yaml
before_script:
  - docker system prune -f --volumes
 
build:
  script:
    - docker build -t $CI_REGISTRY_IMAGE:$CI_COMMIT_SHA .
  after_script:
    - docker system prune -f

Fix 6: Multi-stage Builds to Reduce Image Size

If space is a recurring problem, slim down your images so they don't fill disk in the first place:

dockerfile
# Before: 1.2GB image
FROM node:20
WORKDIR /app
COPY . .
RUN npm install
RUN npm run build
 
# After: ~200MB image with multi-stage
FROM node:20-alpine AS builder
WORKDIR /app
COPY package*.json ./
RUN npm ci
COPY . .
RUN npm run build
 
FROM node:20-alpine AS runner
WORKDIR /app
COPY --from=builder /app/dist ./dist
COPY --from=builder /app/node_modules ./node_modules
CMD ["node", "dist/index.js"]

Set Up Automatic Cleanup

Don't wait until disk is full. Set up a cron job:

bash
# Add to crontab (crontab -e)
# Run docker cleanup every Sunday at 2am
0 2 * * 0 docker system prune -f --filter "until=168h" >> /var/log/docker-cleanup.log 2>&1

The --filter "until=168h" only removes things older than 7 days — safe for production.


Quick Summary

What to deleteCommandRisk
Build cachedocker builder pruneNone
Dangling imagesdocker image pruneNone
Stopped containersdocker container pruneLow
Dangling volumesdocker volume pruneHigh (may have data)
Everythingdocker system prune -a --volumesHigh

Always run with --dry-run first to see what will be deleted.


Docker Hub — use private repos and image retention policies to avoid accumulating old images in your registry too.

KodeKloud Docker Course — the best hands-on Docker training. Covers storage, networking, multi-stage builds, and production best practices.

🔧

Today I Fixed

Short real fixes from production — posted daily

Browse fixes
Newsletter

Stay ahead of the curve

Get the latest DevOps, Kubernetes, AWS, and AI/ML guides delivered straight to your inbox. No spam — just practical engineering content.

Related Articles

Comments