How to fix "No space left on device" on Linux

Your app fails to upload files, updates stop halfway, and Linux gives you the blunt error: No space left on device.

Short version: No space left on device on Linux means the server cannot write new data where it needs to write it. Usually the disk is full, but it can also mean Linux has run out of inodes, which are the tiny file labels it uses to track files. Fix it by finding what is using the space, clearing safe temporary or log data, then setting a plan so one growing folder does not surprise you again.

What does "No space left on device" mean on Linux?

Think of your server disk like a storage room.

Most people imagine one problem: the room is packed from wall to wall. That is the common case. Large logs, backups, uploads, cached packages, database files, old app builds, or Docker data have grown until there is no room left.

But Linux has another limit too: inodes. An inode is like a numbered sticker for a file. Even a tiny empty file needs one. If an app creates millions of small cache files, the room may still have floor space, but Linux has run out of stickers. The result can still be the same literal error string: No space left on device.

So when you search for no space left on device linux, remember there are two questions:

• Is the disk full?
• Or are there too many files?

Both stop new writes. Both can break uploads, deployments, package installs, database writes, and even login sessions.

How do you find what is filling the disk?

Start by checking the big picture. You want to know which part of the server is full, not just guess.

The usual tool is df -h. It shows mounted filesystems in human-readable sizes. If / is at 100%, your main system disk is full. If /var, /home, or another mount is full, the problem is more local.

Then check inodes with df -i. If the inode use is at 100%, the issue is too many files rather than too many gigabytes.

After that, you look for the largest neighborhoods. The command du -h --max-depth=1 /var shows how much space each folder inside /var uses. You can repeat that pattern deeper, like opening cupboards inside the storage room until you find the box taking all the space.

Common places to inspect are:

• /var/log for logs that grew too large.
• /var/lib/docker if Docker images, containers, or logs have piled up.
• /tmp for temporary files that were not cleaned.
• App upload folders for user files, media, or exports.
• Backup folders, especially if backups are stored on the same disk they are meant to protect.
• Database directories, if the app stores a lot of data.

If the server also feels sluggish, a full disk may be only one symptom. Disk pressure can make everything crawl because apps keep trying and failing to write. We cover that wider diagnosis in Why is my server slow?.

What can you safely clear first?

Be careful here. A full disk feels urgent, but random deletion is how a small outage becomes a broken server.

Start with things that are meant to be disposable.

Old compressed logs are often safe to remove if you do not need them for audits or debugging. Temporary files in /tmp are usually less risky than app data, though you should avoid deleting files currently in use. Package manager caches can often be cleared because they are downloaded copies, not the installed software itself.

Docker can also collect leftovers: unused images, stopped containers, old build cache, and large container logs. If you use Docker, treat it like a workshop that never throws away offcuts unless you tell it to. The goal is not to delete your running app; it is to remove the unused material around it.

Be more cautious with these:

• Database files.
• User uploads.
• App configuration.
• Current release folders.
• Anything under /etc.
• Anything you cannot identify.

If backups are filling the same disk, that is a warning sign. Backups should help you recover from trouble, not cause it. A good backup plan includes knowing where the backup lives and whether you can restore it. We explain that in How to back up your server — and actually be able to restore it.

If you are repeatedly running out of room, the server may simply be undersized for what you are asking it to store. Storage is not just for your app code. It also covers logs, databases, uploaded files, caches, updates, and room to breathe. For sizing basics, see What size server do you need?.

FAQ

**Why does Linux say No space left on device when I can still see free space?** You may be out of inodes. Check inode usage with df -i. Too many small files can block new writes even when some storage space remains.

Is it safe to reboot a server with a full disk? Sometimes, but do not treat rebooting as the fix. A full disk can prevent services from starting cleanly if they need to write lock files, logs, or temporary data.

Can I just make the disk bigger? Yes, if your provider supports it, but that only buys time if something is growing without limits. Find the cause first, then resize if the workload truly needs more storage.

Which folder should I never delete blindly? Do not blindly delete databases, app configuration, system configuration, or user uploads. If you do not know what a folder does, identify it before removing it.

The shortcut

Server Manager helps by keeping the server understandable when space problems appear months after setup. Instead of guessing which project owns which folders, you have a clearer picture of what is running and why it exists.

That matters when the real issue is not just “the disk is full,” but a specific failure mode: logs growing without limits, backups sitting on the same disk, old deployments piling up, or one project consuming space that another project needs. The real benefit is that the setup stays legible over time, so cleanup is less like archaeology.

You still need enough storage for your workload. But you are less likely to lose an afternoon tracing mystery files from an app you forgot you deployed.

How do you prevent the next full disk?

Once you have breathing room, make the fix boring.

Keep backups off the main disk when possible. Rotate logs so they do not grow forever. Watch upload-heavy apps more closely than simple brochure sites. Leave spare space for updates and emergencies. If you host several projects on one server, remember that one noisy app can fill the shared storage room for everyone.

No space left on device is scary because it appears after the server has already run out of room. Your win is getting ahead of it: knowing what grew, clearing only what is safe, and leaving the server in a state you can still understand later.