How to find large files on a Linux server
Find large files on a remote Linux server without reading their contents, while accounting for allocation, hard links, permissions, and mount boundaries.
Direct answer
Scan file metadata inside the affected mount, rank regular files by size, and inspect their parent directories. Treat the ranking as a starting point: logical size can overstate sparse-file allocation, hard links can be counted more than once, and unreadable paths can hide results.
When this guide applies
- One mount is almost full and you need the largest visible files.
- A service data directory grew but its biggest child is unclear.
- You need a read-only inventory before contacting the data owner.
Step-by-step review
Select the constrained mount
Use filesystem capacity first so the search targets the device that is actually short on space.
Limit the traversal
Choose the mount point or a narrower application directory and decide whether to stay on that filesystem.
Collect file metadata
Record path, type, logical bytes, allocated blocks when available, modification time, device, inode, and link count.
Sort, then group
Inspect the largest files together with their parent-directory totals; many medium files can matter more than one large file.
Verify ownership and purpose
Confirm the service, retention policy, backup status, and current use before drafting any action.
Technical context
find size tests use defined units
GNU find supports byte and binary-size suffixes, but its -size test rounds values up to the selected unit. A threshold should be read with that rule in mind.
Logical and allocated size are different
A sparse file can have a large logical length while using fewer blocks. Compression, reflinks, copy-on-write, and deduplication can make reclaim estimates filesystem-specific.
Hard links need identity-aware counting
Two paths can refer to the same device and inode. Adding both apparent sizes can exaggerate unique storage consumption.
Filename-safe records matter
Newlines and tabs are legal filename bytes on Linux. A reliable scanner needs structured or NUL-delimited records, not line-based parsing.
Risks and actions to avoid
Largest does not mean disposable
Database files, virtual disks, backups, and active logs may be both large and essential.
Permissions affect visibility
A non-root scan should report unreadable paths instead of presenting a partial list as complete.
Size is not guaranteed reclaim
Deleting one pathname may not release its displayed size because of hard links, snapshots, reflinks, open handles, or filesystem behavior.
What the Omuuz product can—and cannot—do
What it can do
SSH Disk Visualizer can rank visible regular files and directories from metadata and preserve scan-gap warnings beside the result.
What it cannot do
It cannot inspect unreadable paths, determine business value, promise exact reclaimable bytes, or delete a selected file.
Product evidence
