Skip to content

Docker /dev/shm Exhaustion. NCCL Shared Memory Allocation Failure

Docker containers default to 64MB of /dev/shm, which is far too small for NCCL shared memory inter-process communication. Training crashes with 'posix_fallocate failed: No space left on device'. Denpex detects the /dev/shm exhaustion and recommends the correct Docker configuration.

Quick answer

Docker containers default to 64MB of /dev/shm, which is far too small for NCCL shared memory inter-process communication.

Infrastructure#docker#shm#shared-memory#nccl#container#ipc

What this failure is

Docker /dev/shm Exhaustion. NCCL Shared Memory Allocation Failure is a Infrastructure failure seen during ML training runs. Docker containers default to 64MB of /dev/shm, which is far too small for NCCL shared memory inter-process communication. Training crashes with 'posix_fallocate failed: No space left on device'. Denpex detects the /dev/shm exhaustion and recommends the correct Docker configuration. Common tags: Docker, Shm, Shared Memory, Nccl.

Live diagnosis, no signup

Is this what broke your run? Paste your log.

You're reading about Docker /dev/shm Exhaustion. NCCL Shared Memory Allocation Failure. Paste your own crash log or traceback below and get the real root cause for YOUR run, not this generic entry. No account, no card. Logs are masked at ingress and never saved to account history.

training_logs.txt
No log to hand? Try one:

3 free diagnoses/day

Want 14 days on the Scale plan?

Request an evaluation code. A verified workplace organization activates up to 50 diagnoses a day, alerts, history, and follow-up questions. No credit card or automatic subscription.

Evaluate one incident

Why it happens (the mechanism)

Docker sets /dev/shm to 64MB by default, which is too small for NCCL's inter-process shared memory buffers. NCCL allocates shared memory segments for proxy threads, communication channels, and collnet buffers. DataLoader with num_workers > 0 also uses /dev/shm for tensor sharing with the main process. Multiple NCCL communicators (e.g., FSDP sub-communicators) each allocate their own shared memory segments. Taken together, these mechanisms explain why the failure is reproducible, why it tends to surface on specific workloads or scales, and why generic mitigation attempts often fall short without addressing the underlying cause.

What you'll observe

  • NCCL initialization fails with 'No space left on device' inside Docker containers
  • Training works on bare metal but fails inside Docker with shared memory errors
  • The container has plenty of disk space but /dev/shm is exhausted

Common symptoms and what they mean

SymptomWhy it happens
NCCL WARN posix_fallocate failed: No space left on deviceDocker sets /dev/shm to 64MB by default, which is too small for NCCL's inter-process shared memory buffers
ncclShmemOpen failed: cannot allocate shared memory segmentNCCL allocates shared memory segments for proxy threads, communication channels, and collnet buffers
df -h /dev/shm shows 64MB (Docker default) and 100% usageDataLoader with num_workers > 0 also uses /dev/shm for tensor sharing with the main process
Training crashes during NCCL channel or proxy setupMultiple NCCL communicators (e.g., FSDP sub-communicators) each allocate their own shared memory segments

Which systems are affected

  • Docker containers running multi-GPU NCCL training
  • Kubernetes pods without /dev/shm size configuration
  • Any containerized training with DDP/FSDP and NCCL backend
  • Shared memory IPC between DataLoader workers and training processes

How to confirm this is the problem

Use this checklist to test the hypothesis against a small reproduction. No single line proves the root cause, so preserve the preceding events and compare one variable at a time.

  • Reproduce the failure from a clean checkpoint/seed: the symptom must appear without warm-up state from a previous run.
  • Verified signal present: NCCL WARN posix_fallocate failed: No space left on device
  • Verified signal present: ncclShmemOpen failed: cannot allocate shared memory segment
  • Verified signal present: df -h /dev/shm shows 64MB (Docker default) and 100% usage
  • Verified signal present: Training crashes during NCCL channel or proxy setup
  • A targeted fix from the "How to fix it" section eliminates or substantially reduces the symptom within one validation pass.

The fix and the prevention pattern

The root cause is on this page and stays free. A free account adds the exact remediation steps, saved history, and the fix on every entry in the encyclopedia.

Sign up free. Unlock the full analysis

No credit card. Daily allowance follows verified trust tier. Instant access.

Diagnose this failure in VS Code

Select the traceback or open the failed terminal, then run Denpex locally to see the initiating rank, collateral failures, exact fix, and verification command without uploading the log.

Install the free VS Code extension

NCCL errors in context

NCCL is where a distributed job reports failure, which is not the same as where it failed. The hub lists every common NCCL error next to what it actually indicates, and the environment variables that tell them apart.

Compare every nccl error side by side

Root cause

  • Docker sets /dev/shm to 64MB by default, which is too small for NCCL's inter-process shared memory buffers
  • NCCL allocates shared memory segments for proxy threads, communication channels, and collnet buffers
  • DataLoader with num_workers > 0 also uses /dev/shm for tensor sharing with the main process
  • Multiple NCCL communicators (e.g., FSDP sub-communicators) each allocate their own shared memory segments

The fix and how to prevent it

Evaluate Denpex on your own logs

Request a Scale evaluation code. A verified workplace organization activates 14 days with up to 50 diagnoses a day. Every account keeps its current diagnosis allowance and gets a verification path. No card or automatic subscription.

We send a single-use code tied to that address. Static provider and TLD rules do not reject valid addresses. Account trust determines the benefit after signup.

Don't just read the fix, diagnose your run

The encyclopedia tells you what went wrong. Denpex tells you what went wrong in YOUR training run. With your logs, your config, and your stack.