Deploy Error Decoder

ENOSPC: no space left on device — how to fix it

Quick answer: ENOSPC: no space left on device means a write failed because something is full — usually the disk, but it can also be inodes or the inotify watch limit. Check disk with df -h, inodes with df -i, and for the dev error "ENOSPC: System limit for number of file watchers reached" raise fs.inotify.max_user_watches. Then reclaim space — logs and old Docker images are the usual offenders.

Not your exact error? Paste it into the Deploy Error Decoder →
On this page

What the error looks like

Same error code, three different "full" conditions:

Error: ENOSPC: no space left on device, write

# the dev-server flavor:
Error: ENOSPC: System limit for number of file watchers reached

# docker:
failed to register layer: no space left on device

Don't assume "disk full" — a disk with free space can still throw ENOSPC if it's out of inodes or if a watcher hit the inotify limit. Check all three.

Why it happens

The disk is genuinely full

Logs, build artifacts, or a runaway file filled the partition. df -h shows 100%.

Inodes are exhausted

Millions of tiny files used up all inodes while bytes remain. df -i shows 100% IUse.

Docker images and volumes piled up

Old images, dangling layers, and stopped containers quietly consume the disk.

inotify watch limit (dev)

A dev server watching many files hit max_user_watches — not a disk problem at all.

Diagnose it in three steps

1

Check space and inodes

df -h        # bytes used
df -i        # inodes used (a sneaky cause)
2

Find what's eating it

du -sh /var/* 2>/dev/null | sort -h | tail
journalctl --disk-usage
docker system df
3

Reclaim or raise the watch limit

# disk:
docker system prune -af --volumes
journalctl --vacuum-size=200M
# dev file-watcher limit:
sudo sysctl fs.inotify.max_user_watches=524288
The real fix

Stop the disk filling in the first place

Reclaiming space gets you running again; the durable fix is bounding what grows. Rotate logs, prune images on a schedule, and put high-churn data on a volume you monitor:

# rotate app/journal logs so they can't fill the root disk
# (logrotate, journald SystemMaxUse, or your platform's log limits)
# and alert before df hits ~85%, not at 100%.
How Infraveil handles this

Bounded log handling and visible disk pressure

Runaway logs are a common cause of a full disk. Infraveil's customer-side launcher and agent run on your own servers, while the hosted management plane can surface selected logs, service status, and disk-related failures in one place. Retention, rotation, collection limits, and available disk space still depend on customer configuration and must be monitored; Infraveil does not guarantee that a disk cannot fill.

Configure retention, rotation, and collection limits for the host
Failures surface in one status + log view, on servers you control
Configured, bounded recovery may restart services once space is reclaimed

Frequently asked questions

What does ENOSPC mean?

A write failed because a resource is full. Most often the disk, but it can also be inode exhaustion or, in dev, the inotify file-watch limit.

My disk has space but I still get ENOSPC — why?

You're likely out of inodes (check df -i) from many tiny files, or you hit the inotify max_user_watches limit if it's a dev server.

How do I fix 'System limit for number of file watchers reached'?

Raise the limit: sudo sysctl fs.inotify.max_user_watches=524288 and persist it in /etc/sysctl.conf. It's a watcher limit, not a disk issue.

How do I reclaim Docker disk space?

Run docker system df to see usage, then docker system prune -af --volumes to remove unused images, containers, and volumes (be careful with --volumes).

Free tools for this

Client-side, no signup — they run in your browser.