Fix 'Disk quota exceeded' in Linux: Complete Troubleshooting Guide

Understanding the 'Disk quota exceeded' Error

The infamous Disk quota exceeded message appears when a user or group reaches the storage or file count limits set by the system administrator on a Linux filesystem. It can manifest during file writes, compilation, database operations, or even when saving a simple log. This error is not about a full physical disk; it is an enforced boundary designed to prevent a single user or application from monopolizing shared resources. Understanding the underlying quota mechanism is the first step to resolving the issue permanently.

What Is a Disk Quota?

A disk quota is a kernel-managed limit assigned per user, per group, or per project on specific mounted filesystems. Limits come in two flavors:

Block limits (inodes / data blocks): restrict the total disk space (usually measured in kilobytes or megabytes) that can be consumed.
Inode limits: restrict the total number of files and directories, regardless of their total size.

Quotas use a dual-threshold model: a soft limit and a hard limit. When a user exceeds the soft limit, a grace period starts (default usually 7 days), during which they can still create files but receive warnings. Once the grace period expires, or if the hard limit is hit immediately, the kernel denies further writes with the exact error Disk quota exceeded.

Why Quotas Matter for Developers

In shared hosting, university servers, CI/CD pipelines, Docker containers backed by limited volumes, or corporate development environments, quotas prevent a rogue script from crashing the entire server by filling up a shared partition. However, they can abruptly stop a build, corrupt a database transaction, or prevent logging, leaving developers confused about the root cause. Recognizing that the issue is quota-related—not a full disk—saves hours of misdirected troubleshooting. Properly managing quotas ensures predictable resource usage and helps maintain a clean development environment.

Diagnosing the Quota Limit

🚀 Deploy your AI agent in 10 minutes

Managed Hermes hosting. Zero DevOps. 100M tokens/mo included.

Try it free →

Before fixing the problem, confirm that quotas are active and identify which limit was breached. Use the commands below to gather exact details.

# 1. Check your current quota usage and limits
quota -v

# 2. Show quota report for all users (requires root)
sudo repquota -a

# 3. Check quotas on a specific mount point (e.g., /home)
sudo repquota /home

# 4. Display only the user's quota on a specific filesystem
quota -w -u $USER /home

Output from quota -v looks like:

Disk quotas for user developer (uid 1001):
  Filesystem   space   quota   limit   grace   files   quota   limit   grace
  /dev/sda1    500M    400M    500M     none    1200    1000    1200     none

Here, space indicates current usage (500 MB). The quota column shows the soft limit (400 MB) and limit shows the hard limit (500 MB). Since usage equals the hard limit, any further write fails. The grace field shows none because the hard limit was breached directly or grace period expired. Similarly, files and limit track inode usage.

If you see Disk quota exceeded but the quota command reports no limits, quotas may be enabled on a different filesystem or through a project-based scheme. Always verify the exact mount point where the write failure occurs.

Identifying the Culprit Files

Once you know which limit is exhausted (blocks or inodes), locate the largest or most numerous files inside your home directory or the affected directory tree.

# Find files larger than 50 MB in your home directory
find ~ -type f -size +50M -exec ls -lh {} \; | sort -k 5 -h

# Summarize disk usage per directory (top-level folders)
du -h --max-depth=1 ~ | sort -hr

# Check number of files in a directory tree (inode limit)
find ~ -type f | wc -l

If the inode limit is exhausted, you may have thousands of tiny files. Common culprits include node_modules, cached Python bytecode (__pycache__), git objects, log files, or a runaway script that creates temporary files.

Check for Hidden Trash and Caches

Desktop environments often move deleted files to a trash directory that still counts against the user quota. Package managers and development tools maintain large caches.

# Check size of user's trash directory (typical locations)
du -sh ~/.local/share/Trash

# Check package manager caches
du -sh ~/.cache/apt   # Debian/Ubuntu APT cache
du -sh ~/.cache/pip   # Python pip cache
du -sh ~/.cache/yarn  # Yarn package cache
du -sh ~/.npm         # npm cache (older location)
du -sh ~/.gradle      # Gradle build cache

Resolving the Quota Exceeded Issue

Solutions range from cleaning up data to requesting a quota increase. Always start with safe cleanups, then escalate to administrative changes if necessary.

1. Remove Unnecessary Files

Delete large or redundant files you no longer need. Focus on temporary build artifacts, cached libraries, and old logs.

# Remove node_modules in old projects (re-install when needed)
find ~/projects -type d -name "node_modules" -exec rm -rf {} +

# Clear Python bytecode caches
find ~ -type d -name "__pycache__" -exec rm -rf {} +

# Delete files older than 30 days in a specific log directory
find ~/logs -type f -mtime +30 -delete

# Empty the user trash
rm -rf ~/.local/share/Trash/files/*

# Clean pip cache safely
pip cache purge   # Python 3
rm -rf ~/.cache/pip

# Clean npm cache
npm cache clean --force

2. Compress or Archive Old Data

If certain directories contain important historical data that must be retained, compress them to save space and inodes.

# Tar and compress a large folder, then remove original
tar -czvf archive.tar.gz ~/old_project_data && rm -rf ~/old_project_data

3. Move Data to a Different Filesystem

If your quota applies only to /home but /scratch or /tmp is un-quota’d (or has separate limits), move large working sets there. Symbolic links can keep paths consistent.

# Move a large cache directory to /scratch (no quota)
mv ~/.cache/big_workload /scratch/big_workload
ln -s /scratch/big_workload ~/.cache/big_workload

4. Request or Set a Quota Increase

If cleanup is not feasible—maybe the project genuinely needs more space—you can increase the quota. As a regular user, you must ask the system administrator. If you have sudo access, adjust the limits with edquota or setquota.

# Open interactive editor for a user's quota (block limits in KB)
sudo edquota -u username

# Or set quota non-interactively (block soft/hard, inode soft/hard)
sudo setquota -u username 5000000 5500000 20000 25000 /home

The setquota command above sets a soft block limit of 5 GB (5,000,000 KB), hard limit of 5.5 GB, soft inode limit of 20,000 files, and hard inode limit of 25,000 files on the /home filesystem. After changing quotas, the user should run quota -v to verify the new boundaries.

5. Manipulate Grace Periods (Temporary Relief)

If the soft limit is breached but the hard limit still allows writes, you can extend the grace period to buy time for cleanup.

# Check current grace periods
sudo repquota -v /home

# Set block grace period to 10 days (seconds: 864000)
sudo setquota -t 864000 604800 /home   # block grace, inode grace

6. Special Cases: Docker, NFS, and Project Quotas

In Docker containers, the "Disk quota exceeded" error often originates from the host's storage driver or overlay filesystem limits. Verify the host’s underlying XFS or ext4 quotas. For NFS mounts, the error may come from the remote server's quota; contact the NFS administrator. Project-based quotas (used with project ID) require querying with quota -P and adjusting with edquota -P. Always confirm the quota type with repquota -a -P.

Preventing Future Quota Exceeded Errors

Adopting proactive habits eliminates the surprise of a broken pipeline. Integrate quota checks into your daily workflow.

Regular Monitoring and Alerts

Add a simple quota check to your shell profile or a cron job that warns when usage crosses 80% of the soft limit.

# Bash snippet to alert on high quota usage
USAGE=$(quota -w -u $USER | tail -1 | awk '{print $2}')
LIMIT=$(quota -w -u $USER | tail -1 | awk '{print $3}')
if [ "$LIMIT" -gt 0 ] && [ "$USAGE" -gt $(( LIMIT * 80 / 100 )) ]; then
    echo "WARNING: Quota usage over 80% (soft limit $LIMIT KB, used $USAGE KB)"
fi

Automate Cleanup Tasks

Schedule regular cache and temporary file purges. Use tools like tmpreaper or systemd timers.

# Example: clean pip cache weekly via cron
0 2 * * 1 pip cache purge

# Remove logs older than 14 days
0 3 * * * find /home/dev/logs -type f -mtime +14 -delete

Separate Workloads by Filesystem

Keep development projects, container images, and databases on partitions with generous quotas (or no quotas). Mount scratch space specifically for ephemeral builds. Many organizations provide a /scratch or /work mount without strict quotas for active development.

Use Containerized Environments with Volume Controls

When using Docker, always assign explicit volume sizes or mount host directories that respect quota boundaries. Avoid writing inside the container's own ephemeral filesystem for heavy I/O.

Respect Inode Limits

If you work with many small files (e.g., unpacked archives, static site generators), periodically count files and consider packaging them into archives or using a database instead of a flat file tree.

Conclusion

The Disk quota exceeded error is a protective mechanism, not a catastrophic failure. By learning to interpret quota reports, locate space-consuming files, and apply targeted cleanups or limit adjustments, you regain control over your development environment. The best strategy combines regular monitoring, automatic cache clearing, and thoughtful file organization. Treat quota limits as a resource constraint to be managed—just like memory or CPU—and you'll never lose work to a full quota again.