How to Fix 'No space left on device' (Error 28) on Linux Servers

One of the most catastrophic errors a Linux system administrator can encounter is “No space left on device” (Error 28). When a server’s storage hits 100% capacity, MySQL databases instantly crash, Nginx/Apache fails to write access logs (resulting in a 502 Bad Gateway), and you may even be locked out of SSH.

Here is a step-by-step guide to recovering a Linux server that has run out of storage space.

Step 1: Regain SSH Access

If you cannot SSH into your server because the SSH daemon cannot allocate memory or write to the /var/log/auth.log file, you must reboot the server from your hosting control panel. A hard reboot will often clear /tmp files, giving you just enough megabytes to log in.

(If you are facing connection issues unrelated to storage, check our SSH Connection Refused Guide first).

Step 2: The Two Types of Disk Exhaustion

Once logged in, you must determine how you ran out of space. Run this command:

df -h

This checks standard disk usage. Look at the Use% column for the / (root) partition. If it says 100%, you are out of physical block storage.

However, if df -h shows only 40% usage, but you still get the Error 28 message, you have run out of Inodes. Run this command:

df -i

An inode is a data structure that stores metadata about a file. Every file, no matter how small, consumes one inode. If you have a script generating millions of tiny 1-byte files (like unmanaged PHP session files), you will run out of inodes long before you run out of physical gigabytes.

Step 3: Finding and Deleting Large Files (Block Storage)

If you are out of physical storage (df -h is 100%), you need to find the largest directories on your server. Run this command from the root / directory:

sudo du -cha --max-depth=1 / | grep -E "M|G" | sort -h

This will list directories by size. Typically, the culprits are:

• /var/log/: Unrotated Nginx, Apache, or MySQL logs.
• /var/lib/mysql/: Bloated database tables (see our Database Optimization Guide).
• /home/user/backups/: Automated cPanel or Plesk backups that were never deleted.

To safely delete a massive log file without crashing the service currently writing to it, do not use rm. Instead, truncate it:

> /var/log/nginx/access.log

Step 4: Finding and Deleting Millions of Small Files (Inode Exhaustion)

If you are out of Inodes (df -i is 100%), you need to find the directory containing the most files. Run this command:

find / -xdev -printf '%h\n' | sort | uniq -c | sort -k 1 -n | tail -20

This will print the top 20 directories with the highest file counts. Often, this will point to /var/lib/php/sessions/ where millions of expired session files have accumulated.

Because the rm command has an argument limit, attempting to run rm -rf * in a directory with 5 million files will result in an “Argument list too long” error. Instead, use find to delete them in batches:

find /var/lib/php/sessions/ -type f -delete

Conclusion

Running out of storage is a critical failure that can corrupt databases and cause severe downtime. Once you have cleared space, ensure you configure logrotate for your web server logs and monitor your Nextgen Dedicated Server metrics to prevent the issue from recurring.

Expand disk storage dynamically and avoid inode exhaustion with Nextgen Hosting’s VPS.