Linux disk full: find the cause before deleting files

No space left on device does not tell you which files to delete. It may mean a disk is out of storage space, a particular mounted volume is full, or the filesystem cannot create another file.

Start by finding which filesystem the failing operation writes to. The checks below inspect space; they do not delete files, restart services, or resize your server.

This guide uses Ubuntu 24.04 with GNU coreutils 9.4. On a VPS, connect with your existing SSH command. If you followed our VPS setup guide, reuse your full command with -i and your selected key file. Run these commands in the Ubuntu terminal, not Windows PowerShell.

Check the destination, not just the whole server

Read the failed application’s error and identify its destination folder. For example, if it cannot write a log under /var/log, check:

df -h /var/log

df reports the filesystem containing that path. -h makes the sizes easier to read, using units such as G and M. If a new folder has not been created yet, check its nearest existing parent.

Look at Avail, Use%, and Mounted on. Mounted on tells you where that filesystem starts. If /var/log is on the root filesystem, this is /; a separate data volume might instead be mounted at /mnt/data.

The percentages are clues, not a universal alert threshold. Some filesystems reserve space for privileged use, so ordinary users can fail before every reported byte is exhausted.

Check whether the filesystem can create more files

An inode is a filesystem record for a file or directory. A very large number of tiny files can use up these records even when their contents occupy little space.

Check the same destination:

df -i /var/log

Look at IFree and IUse%. If IFree is zero, deleting one large file may free bytes but leave the underlying “too many files” problem mostly unresolved. You need to identify the directory accumulating huge numbers of files and the process creating them.

Some filesystems do not report a fixed inode pool this way. An unusual or unavailable value is not proof of inode exhaustion.

Find the directory using the space

Use the mount point you found earlier. If it was /, run:

sudo du -xhd1 /

sudo grants the administrator access needed to inspect protected directories. Use it only where you are authorized. du estimates directory usage; -x stays on the same filesystem, and -d1 shows one directory level at a time.

If the affected filesystem instead starts at /mnt/data, replace / with /mnt/data. Do not run the root command and assume it includes a separate mounted volume: -x deliberately skips that volume.

Find the largest directory in the output, then inspect that directory one level deeper. For example, if /var is large:

sudo du -xhd1 /var

If /var/log accounts for most of it:

sudo du -xhd1 /var/log

Keep drilling down until you can identify the application’s logs, uploads, backups, or cache. Large scans can take time and cause disk activity; stop one with Ctrl+C if necessary. Do not hide permission or read errors: a partial scan is not a complete inventory.

If the inode check was full instead of the byte check, count filesystem entries rather than their size. For a root filesystem:

sudo du --inodes -x -d1 /

Replace / with the affected mount point when different. Find the largest count, then repeat on that directory, for example sudo du --inodes -x -d1 /var. These counts locate where many entries accumulate; their total need not equal df’s inode allocation exactly. Investigate the generating application before removing its files.

Why df and du may disagree

df reports filesystem allocation; du walks files and directories it can see. Their totals need not match exactly.

One important cause is a deleted file still held open by a running process. Its name is gone, but the process can keep its storage allocated until it closes the file. Deleting more unrelated files does not solve that cause. Ask the service administrator to identify the process and plan a safe log rotation or restart; restarting a service can interrupt users.

Other causes include inaccessible directories, filesystem metadata, snapshots, and data hidden underneath a mount point. If the visible files do not explain the allocation, preserve the outputs and investigate the filesystem or provider’s storage tools. Do not format, unmount, or reboot a working server just to see what happens.

Choose a cleanup you can explain

Before removing anything, establish what owns it and whether you can recover it:

• Old application logs: use that application’s retention or log-rotation settings. Avoid deleting its current open log blindly.
• Backups: confirm you have another usable copy and a retention rule. A large backup is not automatically disposable.
• Uploads or database files: treat them as live data until proved otherwise. Do not delete database files directly from their storage folder.
• Many temporary files: identify the generating task and its supported cleanup method. Otherwise they may immediately return.

There is no safe universal rm command for these cases. If you cannot identify a directory confidently, stop at the diagnosis and ask the application’s operator or hosting support before deleting it.

After an approved cleanup, rerun df -h and df -i for the original destination, then repeat the original write operation. Free-space numbers alone do not prove the application recovered. If usage quickly grows again, correct the retention or runaway task before considering a larger disk.

Your useful result is a named filesystem and a likely source of growth, with the original data preserved. Additional server capacity is a separate decision; it is not the first repair for an unexplained full disk.

Sources and useful links

• Ubuntu df manual — filesystem space, readable units, and inode reporting.
• Ubuntu du manual — one-filesystem scans and directory-depth limits.
• GNU disk-usage tools — explains the different purposes of df and du.