AWS OSError- [Errno 28] No Space Left On Device | Fixes

This error often pops up in the middle of a deploy, a batch job, a container build, or a training run. One minute everything looks fine, the next your process dies with a stack trace that ends in OSError: [Errno 28] No space left on device. On AWS this usually points to a full EBS volume, full ephemeral storage on Fargate or Lambda, or a log or Docker layer that has grown too large.

This article walks through what the message really means on Linux and AWS, quick checks to run, and practical fixes for EC2, EBS, Docker, Lambda, and Fargate. The goal is simple: get your service back online, then tidy things so the same disk issue does not surprise you again.

What Aws Oserror- [Errno 28] No Space Left On Device Means

On Linux, this error comes from the kernel when a write call tries to add data and the backing storage cannot take more. That usually means the block device is full, but it can also mean the inode pool is exhausted or a quota has capped usage for a user or mount. The Python stack trace only shows OSError; the real story lives in your file systems and volumes.

On AWS this message shows up in many places: EC2, EBS-backed volumes, EFS mounts, ECS and Fargate tasks, Lambda functions that write too much to /tmp, or managed tools that write logs and state near a full disk. The core pattern stays the same: your code tries to write a file, log line, temp artifact, or Docker layer, and the device says no.

When you see aws oserror- [errno 28] no space left on device in logs, treat it as a storage capacity problem first, not a Python bug. The fix lives in the storage layer: free space, grow the volume, or move data elsewhere.

Common Root Causes On Aws

• Full root EBS volume — Application data, logs, caches, and package installs have filled / or /var on an EC2 instance.
• Docker layers and images — Old images, containers, and volumes take up gigabytes under /var/lib/docker until the host disk hits the limit.
• Oversized logs — Web server logs, app logs, and rotated archives keep piling up under /var/log or an app directory.
• Temp files in /tmp — Short-lived files from builds, extract jobs, or Lambda runs fill /tmp or other temp paths.
• Ephemeral storage caps — Lambda or Fargate hit their configured temp storage limit and stop writes.
• Inode exhaustion — Millions of tiny files leave space free in df -h but no inodes left in df -i.

Quick Checks When You See This Aws Disk Error

Before making changes in the AWS console, gather a quick snapshot from the machine or container where the error fires. These checks show you whether the problem sits in space, inodes, or a specific mount.

• Check space usage — Run df -h to see which file systems are near 100% and note the mount points with tight free space.
• Check inode usage — Run df -i to see inode use; a mount at 100% here with space left in df -h points to too many small files.
• Find heavy directories — On the full mount, run a command like sudo du -xh --max-depth=1 / | sort -h (adjust the path) to spot large folders.
• Look at /tmp and caches — Check /tmp, build directories, caches, and download folders for large artifacts you no longer need.
• Review logs — Read recent app logs and system logs near the error time; repeated failures can create huge log files by themselves.
• Confirm AWS storage type — In the AWS console, confirm whether the workload sits on EBS, instance store, EFS, Lambda tmp, or Fargate ephemeral storage so you pick the right fix.

These quick checks tell you whether a fast cleanup is enough or if you need to resize an EBS volume, change a task definition, or rework where your app writes data.

Aws No Space Left On Device Error Fixes On Ec2 And Ebs

On EC2, the error nearly always points to a full EBS root volume or a data volume. You have two broad paths: free space that you do not need or expand the EBS volume and extend the file system. In many setups you can modify an EBS volume online, then grow the partition and file system with tools such as growpart, resize2fs for ext, or xfs_growfs for XFS on Linux.

Cause	Where It Shows Up	Fix In Short
Root volume full	/ at 100% in df -h	Clean logs and tmp, then grow EBS volume and file system
Data volume full	Mounted app path at 100%	Archive to S3 or EFS, then resize volume or add a new one
Inode exhaustion	df -i at 100% with space left	Remove tiny files, rework folder layout or archival flow

Step 1: Free Obvious Space Safely

• Prune old app logs — Compress or remove old .log and rotated .gz files once you no longer need them for audits or debugging.
• Drop stale build artifacts — Remove old release bundles, large cache folders, and forgotten backup archives under your app directories.
• Vacuum package caches — Clean package manager caches with commands such as sudo apt clean or the matching command for your distro.

Step 2: Resize The Ebs Volume If Needed

• Modify the volume in the console — In the EC2 console, open the EBS volume, choose Modify volume, and set a larger size that fits your growth pattern.
• Extend the partition — On the instance, use growpart or a similar tool to extend the partition that holds the file system into the new space.
• Grow the file system — Run resize2fs for ext file systems or xfs_growfs for XFS so the file system can use the expanded volume space.

Many modern AWS Linux images already run a resize step at boot when extra space is present, which can save a manual resize2fs run in some cases. Still, do not assume this; always confirm with df -h after a resize so you know the file system can use the new capacity.

Step 3: Move Cold Data Off The Instance

• Archive to S3 — Ship old logs, exports, and reports to S3 buckets with lifecycle rules that push very old data to cheaper storage classes.
• Use EFS for shared files — Place shared datasets, user uploads, or shared config on EFS so multiple instances do not duplicate the same data on their root disks.
• Split hot and cold storage — Keep only hot, recent data on the instance and keep long-term data in S3, EFS, or a database.

Cleaning Docker, Logs, And Temp Data On Aws

Docker builds and containers are a frequent source of aws oserror- [errno 28] no space left on device on EC2 and container hosts. Each image layer, stopped container, and anonymous volume eats into /var/lib/docker, which often sits on the same EBS volume as the root file system.

Prune Docker Space Safely

• Measure Docker usage — Run docker system df to see how much space images, containers, and volumes use on the host.
• Remove unused images — Use docker image prune or docker image prune -a once you confirm that old images are no longer needed for rollbacks.
• Prune stopped containers — Run docker container prune to drop stopped containers that just hold logs and layer data.
• Clean unused volumes — Use docker volume prune to remove orphaned volumes that no longer connect to running containers.

Keep Logs And Temp Files Under Control

• Rotate logs aggressively — Tune logrotate or your logging agent so logs rotate daily or by size and do not keep endless archives on the same volume.
• Send logs off-host — Forward logs to CloudWatch Logs, an external log service, or another sink so local log retention can stay short.
• Clean build temp paths — Make build jobs delete their temp folders after a run, especially when builds write gigabytes under /tmp or workspace paths.

When you apply these cleanups on a schedule, you slow down growth and give yourself more room before the next resize. Combine them with monitoring so you do not get surprised by a sudden full disk in the middle of a busy period.

When Aws Oserror- [Errno 28] No Space Left On Device Hits Lambda Or Fargate

In serverless and managed container setups you often cannot log into the host to run df -h. The same error still comes from full temp storage, but the fix lives in configuration and code patterns rather than manual cleanup.

Lambda /tmp Storage Limits

Each Lambda function gets temp storage under /tmp. You can configure it between 512 MB and 10,240 MB, and writes above that limit can trigger no-space errors. Heavy downloads, unpack steps, or local caching can fill this space quickly.

• Right-size ephemeral storage — In the Lambda console or IaC template, raise the ephemeral storage setting for workloads that need large temp workspaces.
• Stream to S3 instead — For long-lived artifacts, stream data straight to S3 rather than first writing full files under /tmp.
• Delete temp files early — Remove temp files at the end of each handler run once you no longer need them; do not wait for the process to recycle.

Fargate Ephemeral Storage

Fargate tasks get 20 GiB of ephemeral storage by default and can be configured up to 200 GiB per task. This space backs Docker layers, container logs, and anything under the container file system that is not on a mounted volume. If a job writes large files to local paths or logs heavily, it can burn through that quota.

• Increase task storage — Add the ephemeralStorage block in the task definition with a larger size in GiB for heavy data workloads.
• Mount EFS or EBS where needed — For shared or long-term data, mount EFS or an attached volume instead of leaving data on the task’s ephemeral disk.
• Trim container logs — Limit log verbosity and use log drivers that ship data out so local log files do not grow unchecked.

These changes shift Lambda and Fargate away from patterns that pile too much data into their temp storage, where the aws oserror- [errno 28] no space left on device error often appears first.

Preventing The Aws Disk Full Error In Future

Once you clear the current incident, spend a little time on guardrails so you do not face the same message again during a busy deploy or peak traffic. Storage growth is steady and predictable in many systems, so simple checks already help a lot.

Watch Disk And Temp Usage

• Add CloudWatch alarms — Send disk usage metrics for EBS volumes, EC2 instances, and Fargate tasks to CloudWatch and set alarms at sane thresholds such as 70% and 85%.
• Track growth over time — Review graphs for disk use and temp storage so you can plan volume changes before reaching the edge.
• Alert on inode use — On file-heavy systems, send inode usage metrics so a flood of tiny files does not block new writes while there is still space.

Build Storage-Aware Habits

• Bake cleanup into jobs — Make batch jobs, builds, and data pipelines clean up their own temp folders and staging areas before they exit.
• Separate data tiers — Keep hot data on fast local volumes and move cold data to S3 or other storage so your root disks stay lean.
• Standardize log retention — Decide on retention windows and log shipping patterns so logs do not grow without bound in any service.

With these habits in place, aws oserror- [errno 28] no space left on device becomes a rare event instead of a weekly fire drill. You know where your data lives, which AWS storage tier holds it, and how much headroom each part of the stack still has.