Free Disk Space on Ubuntu

By Kokil Thapa | Last reviewed: September 2026

A full root partition is one of the fastest ways to take down a production site. When you need to free disk space on Ubuntu, the goal is not aggressive deletion—it is finding what grew, reclaiming safe targets, and fixing the process that filled the disk. I've seen Laravel apps fail mid-deploy, MySQL refuse writes, and cron backups stop because /var hit 100%. This guide walks through the commands and paths I use on Ubuntu servers I administer for clients, from quick triage to long-term prevention.

How do you check disk usage on Ubuntu before deleting anything?

Never delete files until you know which mount is full and which directory owns the growth. Ubuntu separates system data across partitions or LVM volumes, and a full /var partition can leave /home mostly empty.

Start with filesystem-level usage

Run df -h for human-readable totals. Add -i when inode exhaustion is suspected—common with millions of small cache or session files.

df -h
df -hi
lsblk -f

The df output shows Use% per mount. Focus on mounts above 85%. At 95%, services start failing unpredictably. On web servers I maintain, /, /var, and sometimes /home are the usual suspects.

Drill into directories with du

Once you know the mount, scan top-level folders. The -x flag keeps du on one filesystem, which avoids crossing into other mounts.

sudo du -xh /var --max-depth=1 | sort -hr | head -20
sudo du -xh /home --max-depth=2 | sort -hr | head -20
sudo du -xh / --max-depth=1 2>/dev/null | sort -hr | head -15

For faster scans on large trees, install and use ncdu. It gives an interactive breakdown and is easier than parsing long du lists during an outage.

sudo apt install ncdu
sudo ncdu /var

Pair this with the deeper patterns in our log rotation and disk space management guide. Logs and journals are repeat offenders on servers that have run for months without housekeeping.

What are the safest ways to free disk space on Ubuntu?

Safe cleanup targets are regenerable caches, old package files, rotated logs, and stale deploy artefacts. Risky targets include live databases, current application releases, and anything you cannot restore from backup.

Clean APT package cache and orphaned packages

Ubuntu stores downloaded .deb files under /var/cache/apt/archives/. After upgrades, old kernels and unused dependencies often remain. This is usually the first reclaim step after triage.

sudo apt clean
sudo apt autoclean
sudo apt autoremove --purge
sudo apt autoremove --purge -y

Before removing kernels, confirm the running kernel:

uname -r
dpkg --list | grep linux-image

Keep the running kernel and at least one previous version. Removing the active kernel breaks boot recovery. For package behaviour details, see our apt update explained guide.

Trim systemd journal logs

On Ubuntu 22.04 and 24.04 servers, /var/log/journal/ can grow to multiple gigabytes. The journal is useful for debugging, but unbounded retention fills disks quietly.

journalctl --disk-usage
sudo journalctl --vacuum-size=500M
sudo journalctl --vacuum-time=14d

Make the limit permanent in /etc/systemd/journald.conf:

[Journal]
SystemMaxUse=500M
SystemKeepFree=1G
MaxRetentionSec=14day

Then reload: sudo systemctl restart systemd-journald. Official behaviour is documented in the systemd journald.conf manual.

Handle Snap packages and old revisions

Snap keeps multiple revisions of each package. On desktop and some server setups, /var/lib/snapd/ can consume tens of gigabytes over time.

snap list --all
sudo snap set system refresh.retain=2
LANG=C snap list --all | awk '/disabled/{print $1, $3}' |
  while read snapname revision; do
    sudo snap remove "$snapname" --revision="$revision"
  done

Our Ubuntu Snap packages explained article covers when Snap is worth keeping versus switching to native packages on servers.

How do you free disk space on Ubuntu web and database servers?

Generic cleanup fixes many incidents. Production web stacks have predictable growth patterns tied to deploys, databases, and PHP runtime behaviour. I've cleared full disks on sister sites sharing a Deployer 7 pipeline—old releases and uncompressed logs were the culprits, not mysterious system bloat.

Laravel and PHP-FPM deploy artefacts

Zero-downtime deploy tools keep multiple release directories. Without a retention policy, each deploy adds 200–800 MB depending on vendor/ size and committed frontend builds.

ls -la /var/www/example.com/
du -sh /var/www/example.com/releases/*
ls -lt /var/www/example.com/releases/ | head

Keep the current release, the previous one for rollback, and delete older folders manually or via Deployer keep_releases. After symlink swap, run php artisan optimize:clear only on the active release—not across deleted paths.

For full server context, read our Symfony deployment on Ubuntu VPS guide and Ubuntu server setup guide. Patterns overlap across PHP frameworks.

MySQL and PostgreSQL growth

Database directories under /var/lib/mysql/ or /var/lib/postgresql/ grow with data and binlogs. Never delete files manually while the service runs. For MySQL binary logs:

sudo mysql -e "SHOW BINARY LOGS;"
sudo mysql -e "PURGE BINARY LOGS BEFORE NOW() - INTERVAL 7 DAY;"

Set expire_logs_days or binlog_expire_logs_seconds in MySQL config. Our install MySQL on Ubuntu guide covers baseline tuning. On booking platforms like Adventure Third Pole Trek, unbounded binlogs filled a 40 GB volume within weeks until retention was configured.

PHP sessions, opcache, and temporary uploads

Check session save paths in php.ini—often /var/lib/php/sessions. Stale sessions accumulate if garbage collection is misconfigured. Large imports may land in /tmp or storage/app/tmp/.

grep session.save_path /etc/php/8.3/fpm/php.ini
sudo find /var/lib/php/sessions -type f -mtime +7 | wc -l
sudo find /tmp -type f -mtime +3 -size +10M -ls

PHP 8.3 and 8.4 remain widely deployed; PHP 8.5 is current for new installs. Match the FPM pool config path to your installed version. See install PHP on Ubuntu for version management.

Docker, Nginx, and Apache log volumes

Container logs default to JSON files under /var/lib/docker/containers/. A noisy application can write gigabytes per day without log rotation at the daemon level.

docker system df
docker system prune -f
docker system prune -a --volumes

Review output before confirming -a. Pruning removes unused images that you may need on the next deploy. Configure /etc/docker/daemon.json log limits:

{
  "log-driver": "json-file",
  "log-opts": {
    "max-size": "10m",
    "max-file": "3"
  }
}

Web server access logs under /var/log/nginx/ or /var/log/apache2/ need logrotate. If rotation is broken, a single access log can exceed 10 GB on a busy site. See install Nginx on Ubuntu for baseline config.

What commands find large files quickly on Ubuntu?

When du shows a heavy directory but not the exact file, use find with size filters. This is faster than opening every subdirectory manually during an incident.

sudo find /var -xdev -type f -size +100M -exec ls -lh {} \; 2>/dev/null | sort -k5 -hr
sudo find /home -xdev -type f -size +500M -ls 2>/dev/null
sudo find / -xdev -type f -size +1G 2>/dev/null

Common surprises include forgotten SQL dumps in home directories, uncompressed backup tarballs, and IDE remote-sync folders on developer machines.

Identify open-but-deleted files

A process can hold a deleted file open, so space is not reclaimed until the process restarts. This shows zero size in ls but full usage in df.

sudo lsof +L1 | head -30
sudo lsof +L1 | grep deleted

Restart the owning service—often Apache, PHP-FPM, MySQL, or a long-running backup script. On one legal-tech portal, a log file deleted with rm while Apache kept it open held 6 GB until systemctl reload apache2 ran.

Check inode usage separately

A partition can report free space while inodes are exhausted. Millions of small session or cache files cause this pattern.

df -hi
sudo find /var/lib/php/sessions -type f | wc -l

Fix inode pressure by cleaning the directory or changing session storage to Redis 8.10. Pair monitoring with our Ubuntu server monitoring guide so you get alerts before either metric hits 100%.

How do you prevent Ubuntu disks from filling up again?

One-time cleanup fixes the symptom. Prevention stops the 3 a.m. pager. Treat disk budgets like any other production constraint—especially on budget VPS plans common for Nepal SMB sites at Rs 1,500–3,000/month (~USD 11–22).

1. Set log rotation and journal caps. Configure logrotate for every custom app log. Cap systemd journal size as shown above.
2. Automate package and cache cleanup. A weekly cron running apt autoremove --purge -y and apt autoclean prevents kernel and cache drift.
3. Limit deploy release retention. Set keep_releases: 3 in Deployer. Old releases are your cheapest rollback insurance—not an archive.
4. Size backups off the root volume. Nightly mysqldump files belong on object storage or a separate mount—not /var/backups on a 25 GB VPS.
5. Monitor with thresholds. Alert at 80% disk use, not 98%. Include inode checks in the same alert rule.
6. Audit uploads and exports. Admin CSV exports and document uploads on client portals fill disks silently over months.

Example weekly cleanup cron as root (/etc/cron.weekly/disk-housekeeping):

#!/bin/bash
apt autoremove --purge -y
apt autoclean -y
journalctl --vacuum-size=500M
find /var/www/*/releases -maxdepth 1 -mindepth 1 -type d | sort -r | tail -n +4 | xargs -r rm -rf

Adjust the release path pattern to your layout. Test on staging first. Sites like Notary Kathmandu share infrastructure where one full disk affects multiple vhosts—housekeeping cron is not optional.

Harden the broader stack with server hardening for Ubuntu web servers and Ubuntu security hardening. Security and housekeeping overlap when logs and temp directories grow without bounds.

If you need a quick JSON or config check while editing logrotate or daemon configs, the JSON formatter tool on this site saves a round trip to another tab. For ongoing ops, support and maintenance services and testing and optimization cover monitoring setup and recurring cleanup policies.

Ubuntu’s official storage guidance lives in the Ubuntu Server storage documentation. Cross-check mount options and LVM behaviour there before resizing volumes.

Key Takeaways

• Run df -h and du -xh before deleting anything—know the mount and the directory first.
• Safe wins: apt clean, apt autoremove --purge, journalctl --vacuum-size=500M, old deploy releases, and rotated logs.
• Never manually delete files under /var/lib/mysql/, active storage/, or the current deploy release symlink.
• Check lsof +L1 for deleted-but-open files that hide free space from df.
• Cap journals, rotate web logs, limit Docker log size, and set MySQL binlog retention before the disk hits 100%.
• Alert at 80% disk use and automate weekly housekeeping cron on every production Ubuntu server.

People Also Ask

What does it mean when Ubuntu says "no space left on device"?

The error means a filesystem reached 100% capacity or inodes are exhausted. Writes fail for logs, sessions, uploads, and database transactions. Run df -h and df -hi immediately to see which mount failed, then free disk space on Ubuntu using safe cleanup targets before restarting services.

Is it safe to delete everything in /var/log?

No. Do not bulk-delete active logs. Truncate or remove only rotated files ending in .gz, .1, or dated suffixes. Use journalctl --vacuum-size for systemd journals. Confirm logrotate is configured so files regenerate correctly after cleanup.

How much free disk space should an Ubuntu server keep?

Keep at least 15–20% free on root and /var for stable operation. On a 40 GB VPS, that is roughly 6–8 GB headroom. Set monitoring alerts at 80% use so you clean up during business hours—not during a production outage.

Can I extend the disk without deleting files on Ubuntu?

Yes, if the volume manager or cloud provider supports it. Grow the block device in your VPS panel, run growpart on the partition, then resize2fs for ext4 or xfs_growfs for XFS. Expansion solves capacity; it does not replace log rotation or release retention—you still need housekeeping.

Recover headroom before the next deploy breaks

Free disk space on Ubuntu is a repeatable process: measure with df and du, reclaim caches and logs, fix the growth source, and automate retention. Blind rm -rf causes more downtime than a full disk ever did. If your production server is already throwing write errors—or you want monitoring and cleanup baked in from day one—contact us for server administration help, or explore Linux system administration in Nepal and hosting setup before the next incident. Browse the portfolio for production sites that run on the same Ubuntu hygiene patterns, and read more on the blog or homepage for related DevOps guides.