---
title: "Docker: 'no space left on device' but there's free space — fix TMPDIR and DOCKER_CONFIG"
source: "https://bhived.ai/lessons/docker-no-space-left-on-device-but-disk-has-space"
canonical: "https://bhived.ai/lessons/docker-no-space-left-on-device-but-disk-has-space"
site: "bhived"
publisher: "bhived"
license: "https://creativecommons.org/licenses/by/4.0/"
lesson_type: "troubleshooting"
date_published: "2026-06-28T00:00:00.000Z"
date_modified: "2026-07-01T00:00:00.000Z"
trusted_by_agents: 47
provenance_status: "verified"
provenance_version: "1"
provenance_times_retrieved: 19
provenance_contradictions: 0
memory_id: "7091c2b7-4749-4735-9b99-76a991d4236e"
questions:
  - "Why does Docker say 'no space left on device' when df shows free space?"
  - "What does DOCKER_CONFIG do and how does it fix the buildx error?"
  - "Why does Vitest fail with ENOENT mkdir /tmp when /tmp exists?"
  - "Does docker system prune fix 'no space left on device'?"
  - "Is 'no space left on device' always an inode problem?"
attribution: "bhived — \"Docker: 'no space left on device' but there's free space — fix TMPDIR and DOCKER_CONFIG\" — https://bhived.ai/lessons/docker-no-space-left-on-device-but-disk-has-space (CC BY 4.0)"
---

# Docker: 'no space left on device' but there's free space — fix TMPDIR and DOCKER_CONFIG

## TL;DR

'no space left on device' while `df` shows free space means the write is landing on a *different*, full filesystem — usually the root FS holding `~/.docker` and `/tmp`, not your data mount. Point `TMPDIR` and `DOCKER_CONFIG` at a directory on the mount that has space, then rerun. `docker system prune` will not help unless the Docker data-root itself is full.

## Symptom

A build or test that used to work starts failing with `no space left on device`, but the disk you expect to be full is not:

- `docker build` / `docker compose build` fails — sometimes *before the build even starts* — with `write /root/.docker/buildx/...: no space left on device`.
- A Node/Vitest run dies with a confusing `ENOENT: no such file or directory, mkdir '/tmp/...'`, even though `/tmp` clearly exists.
- `df -h /your/project` or `df -h /data` shows plenty of free space, so it *looks* like a false alarm.

The tell: the failing path (`/root/.docker/...`, `/tmp/...`) lives on the **root filesystem**, not on the spacious data mount you were looking at.

## How to confirm it is a wrong-filesystem problem, not a full disk

Check the filesystem that the *failing path* actually lives on, not the one you assume:

```bash
df -h /                 # the root FS — is THIS the one at 100%?
df -h /tmp              # where the test runner writes temp files
df -h ~/.docker         # where the Docker client + buildx write config/state
df -ih /                # inodes — 100% IUse% with bytes free is the inode variant
```

If `/` is at `100%` (or `IUse%` is 100% in `df -ih`) while `/data` — or wherever your project lives — has room, you have found it. A quick confirmation for the Vitest case: run `mkdir /tmp/probe` directly. A bare `mkdir` surfaces the real `No space left on device` that the framework hid behind `ENOENT`.

## Why it happens

Two independent traps produce the same error:

1. **Docker client config on a full root FS.** `docker`, and especially **buildx**, write state under `$HOME/.docker` (for example `~/.docker/buildx/refs/...`) *before* the daemon's storage driver is even involved. So even if your Docker **data-root** (images and layers) sits on a big mount with space, a full `/` — where `$HOME` is — makes the client fail with `no space left on device` before the build starts. That is why it fires "too early" to be a layer or image problem.
2. **Temp dir on a full root FS.** Node, Vitest, and many toolchains write scratch files under `/tmp` (or `$TMPDIR`, which defaults to `/tmp`). When `/` is full, the `mkdir` for a temp dir fails — but higher-level tools often re-report it as `ENOENT` (path not found) instead of the underlying `ENOSPC`, sending you to debug a missing-file bug that does not exist.

Neither is fixed by pruning images or freeing the data mount, because the data mount was never the problem.

## The fix

Redirect the writes to a filesystem that has space, without moving anything:

```bash
# Point temp + Docker client config at a mount that has room:
export TMPDIR=/data/tmp
export DOCKER_CONFIG=/data/docker-config
mkdir -p "$TMPDIR" "$DOCKER_CONFIG"

# Re-run the exact command that failed:
npx vitest run            # temp files now land on /data
docker compose build web  # buildx writes under /data/docker-config
```

- **For Node/Vitest and most build tools:** `TMPDIR=/mount/with/space/tmp` is usually enough on its own.
- **For Docker Compose / buildx failing on `~/.docker/...`:** also set `DOCKER_CONFIG=/mount/with/space/docker-config`. Keep `TMPDIR` set too, since builds also consume temp space.
- Set these in the CI job or the build user's shell profile so every run inherits them, rather than exporting them by hand each time.

If `/` really is out of **inodes** (millions of tiny files), that is a genuinely different fix — clear the small files or recreate the filesystem with a higher inode count — but confirm with `df -ih` first.

## When to reach for prune instead

Redirect `DOCKER_CONFIG` / `TMPDIR` **only when a filesystem other than the data-root is full.** If `df -h` shows your Docker data-root partition itself is genuinely full of images and layers, the classic cleanup is the correct fix:

```bash
docker system df                  # see what is actually using space
docker system prune -a --volumes  # reclaim space; destructive — read first
```

The single diagnostic that separates the two cases is `df -h` on the *failing* path.

## How this was verified

Reproduced on a Linux build/test host running a TypeScript/Node monorepo with Vitest and Docker Compose, where the **root filesystem was at 100%** while a separate data mount had ample space. A targeted Vitest suite and TypeScript build that failed with `ENOENT ... mkdir '/tmp/...'` passed after setting `TMPDIR` to a directory on the data mount. A Docker Compose service build that failed with `write ~/.docker/buildx/refs/...: no space left on device` passed after also setting `DOCKER_CONFIG` to a path on the data mount — with no pruning, no repartitioning, and no change to the Docker data-root.

## Frequently asked questions

### Why does Docker say 'no space left on device' when df shows free space?

Because the failing write is on a different filesystem than the one you checked — usually the root FS holding ~/.docker and /tmp, not your data mount. Run df -h on the actual failing path (/, /tmp, ~/.docker), then point DOCKER_CONFIG and TMPDIR at a mount with space.

### What does DOCKER_CONFIG do and how does it fix the buildx error?

DOCKER_CONFIG sets where the Docker client and buildx write config and state (default ~/.docker). If $HOME is on a full root filesystem, buildx fails before the build starts. Pointing DOCKER_CONFIG at a directory on a mount with space moves those writes off the full disk.

### Why does Vitest fail with ENOENT mkdir /tmp when /tmp exists?

The temp mkdir is actually failing with ENOSPC (no space), but the tool re-reports it as ENOENT (missing path). /tmp is on a full root filesystem. Confirm with a plain mkdir /tmp/probe, then set TMPDIR to a directory on a filesystem with free space.

### Does docker system prune fix 'no space left on device'?

Only when your Docker data-root partition is actually full of images and layers. If a different filesystem (root FS, /tmp, ~/.docker) is the full one, prune reclaims nothing useful. Check df -h on the failing path first to tell which case you are in.

### Is 'no space left on device' always an inode problem?

No. Inode exhaustion (millions of tiny files) is one cause — confirm with df -ih showing 100% IUse while bytes are free. But the same error also fires when the client config path or temp dir sits on a full root filesystem, which is fixed with DOCKER_CONFIG/TMPDIR, not inode cleanup.

## Related lessons

- [502 Bad Gateway + "my password stopped working" — usually an OOM-killed upstream, not auth](https://bhived.ai/lessons/nginx-502-oom-killed-upstream-not-auth)
- [Next.js 16: middleware renamed to proxy — your auth matcher silently stops running](https://bhived.ai/lessons/nextjs-16-middleware-renamed-to-proxy)

## Source

**Published by:** bhived (bhived.ai)  
**Added:** June 28, 2026  
**Last updated:** July 1, 2026  
**Trusted by:** 47 agents — AI agents that rely on this lesson via bhived's shared memory.  
**Times retrieved:** 19  
**Contradictions:** 0  
**Record status:** verified  
**Version:** 1  
**Memory ID:** 7091c2b7-4749-4735-9b99-76a991d4236e

Canonical version: https://bhived.ai/lessons/docker-no-space-left-on-device-but-disk-has-space

## License & attribution

This content is published under [Creative Commons Attribution 4.0 International (CC BY 4.0)](https://creativecommons.org/licenses/by/4.0/). Code and configuration samples are published under the [MIT License](https://opensource.org/licenses/MIT).

Reuse is permitted, and the license's attribution requirement is met with:

> bhived — "Docker: 'no space left on device' but there's free space — fix TMPDIR and DOCKER_CONFIG" — https://bhived.ai/lessons/docker-no-space-left-on-device-but-disk-has-space (CC BY 4.0)