Tutorial: Managing Disk Space: Finding Largest Files via SSH on Ubuntu/Debian
Published: 2026-07-15 15:17 (2 comments)
· 2 min read
Effective server maintenance requires regular monitoring of disk space usage. When a disk partition nears capacity, identifying the largest files is the most efficient way to reclaim space. The following guide details two methods for locating large files on Ubuntu and Debian systems using the command line.
Method 1: Using the find Command
The find command is highly efficient for locating files that exceed a specific size threshold. This is useful when searching for files larger than a defined limit (e.g., 500MB).
find /path/to/directory -type f -size +500M -exec ls -lh {} +
/path/to/directory: The starting point for the search.-type f: Specifies that only files (not directories) should be listed.-size +500M: Filters for files larger than 500 Megabytes.-exec ls -lh {} +: Executes thels -lhcommand to display details.
Method 2: Using the du and sort Commands
For identifying the “Top N” largest files or directories, combining du (disk usage) with sort is the preferred approach. This provides a ranked list.
du -ah /path/to/directory | sort -rh | head -n 10
du -ah: Calculates disk usage for all files and directories in human-readable format.sort -rh: Sorts the results by size in reverse (largest first) and interprets human-readable numbers (e.g., K, M, G).head -n 10: Restricts the output to the top 10 results.
Sample Output
The execution of the du command produces an output similar to the following:
4.2G /var/lib/docker/containers/a1b2c3d4/a1b2c3d4-json.log 2.1G /var/log/syslog 1.8G /home/user/backups/db_backup.sql 950M /usr/share/zoneinfo/data.bin ...
Sources
Related articles
2 comments
Both commands belong in the muscle memory of anyone maintaining a server,and the example output naming the Docker log first is painfully accurate.
Neither helps in the case we hit last month, though: a partition reported as full while both commands found nothing worth deleting. Is there a third thing to check?
Two, and they cover almost every case where the usual pair comes up empty.
The first is inodes:
df -i. A filesystem can be sixty percent full by bytes and completely out of inodes, at which point writes fail with the same message as a full disk. The cause is always the same shape — millions of tiny files in one place, typically a mail queue, a session directory or an unrotated cache. Neitherfind -sizenorduranks them, because individually they are nothing.The second is deleted-but-open files: a log that was removed while a process still holds it keeps its blocks until that process closes or restarts.
dfcounts the space,ducannot see the file, and the discrepancy between the two is the tell.lsof +L1lists them. Between those two checks and the two in the article, the disk has nowhere left to hide.