FreePBX Disk Full Suddenly? Fix “No Space Left on Device” Without Breaking Calls

FreePBX systems often run perfectly for weeks, then suddenly fail with: disk full, HTTP 500, backups failing, recordings not saving, voicemail errors, or even Asterisk refusing to reload configuration.

The tricky part: “disk full” is usually not a single issue. It’s almost always a combination of: logs, call recordings, voicemail, and sometimes database growth or backup archives.

This guide shows the fastest safe recovery steps (so calls start working again), then the correct long-term prevention setup.

Disk-Full Symptoms People Search For (Real-World)

• FreePBX dashboard not loading / “Internal Server Error”
• Asterisk can’t write recordings / voicemail
• “No space left on device” in logs
• Call recordings folder suddenly huge
• Backups failing or growing endlessly
• Server becomes slow, SSH feels laggy

When disk is full, even normal services break because Linux cannot write temporary files, logs, PID files, or database changes.

FreePBX Disk Usage Map (What Usually Eats Space)

Your first goal is to identify which category is growing, then clean up safely (without deleting important data blindly).

Step 0 — Confirm Disk Is Actually Full (Not Inode Exhaustion)

Disk full and inode full are different problems. Check both.

df -h
df -i

If df -h shows 100% used, it’s capacity. If df -i shows 100% used, you ran out of inodes (too many tiny files), which often happens with runaway logs or temp files.

Step 1 — Find the Biggest Directory Fast (Safe Commands)

Start at root, then go deeper. This approach is safe and fast.

sudo du -xhd1 / 2>/dev/null | sort -h
sudo du -xhd1 /var 2>/dev/null | sort -h
sudo du -xhd1 /var/log 2>/dev/null | sort -h
sudo du -xhd1 /var/spool 2>/dev/null | sort -h
sudo du -xhd1 /var/spool/asterisk 2>/dev/null | sort -h

Notes:

• -x prevents crossing into other mounted disks.
• -d1 shows one level deep so you can quickly narrow down.
• sort -h sorts human-readable sizes correctly.

Emergency Recovery: Free Up Space Immediately (Without Deleting Business Data)

If you need calls and FreePBX UI working right now, free 500MB–2GB quickly using log cleanup and cache removal.

1) Clear package cache (safe)

# Debian/Ubuntu based
sudo apt-get clean

# RHEL/CentOS/Rocky based
sudo yum clean all
sudo dnf clean all

2) Vacuum old journal logs (safe)

sudo journalctl --disk-usage
sudo journalctl --vacuum-time=7d

3) Find giant single log files (common root cause)

sudo find /var/log -type f -size +200M -exec ls -lh {} \; 2>/dev/null | sort -k5 -h

If you find a runaway log (example: /var/log/asterisk/full or web server logs), you can truncate it safely:

# Example: truncate without deleting the file handle
sudo truncate -s 0 /var/log/asterisk/full

Why truncate instead of delete? Some services keep file handles open. Truncating keeps the same file but clears its content.

Most Common Cause #1: Call Recordings Took All Space

Call recordings are usually stored in:

/var/spool/asterisk/monitor

Confirm size:

sudo du -sh /var/spool/asterisk/monitor
sudo find /var/spool/asterisk/monitor -type f -name "*.wav" -o -name "*.mp3" 2>/dev/null | wc -l

Safe cleanup strategy for recordings

• Do NOT randomly delete recent recordings (usually needed for QA/compliance).
• Delete by age (example: older than 90 days) after confirming policy.
• Prefer moving to external storage or mounting a bigger disk.

Delete recordings older than X days (example: 90 days)

# Preview first (no delete)
sudo find /var/spool/asterisk/monitor -type f -mtime +90 -print | head

# Then delete
sudo find /var/spool/asterisk/monitor -type f -mtime +90 -delete

If you want safer “two-step” cleanup:

# Move old files to a temporary folder first
sudo mkdir -p /root/old-recordings
sudo find /var/spool/asterisk/monitor -type f -mtime +90 -exec mv -n {} /root/old-recordings/ \;

Then you can confirm and delete later.

Most Common Cause #2: Voicemail Storage Grew Quietly

Voicemail lives here:

/var/spool/asterisk/voicemail

Check usage:

sudo du -sh /var/spool/asterisk/voicemail
sudo du -xhd2 /var/spool/asterisk/voicemail 2>/dev/null | sort -h

Common voicemail problems

• Users never delete messages
• Voicemail-to-email keeps copies on disk
• Old mailboxes remain after extensions are removed

Safe cleanup options

• Remove voicemail for deleted extensions only (best)
• Delete messages older than X days if policy allows

# Preview voicemail audio older than 180 days
sudo find /var/spool/asterisk/voicemail -type f -mtime +180 -print | head

Most Common Cause #3: Asterisk Logs Exploded

Asterisk log growth is a classic “new server” issue, especially when debugging was enabled (SIP logging, verbose debug, or a misbehaving trunk causing constant errors).

Check log directory sizes

sudo du -sh /var/log/asterisk
sudo ls -lh /var/log/asterisk | head

Check if SIP debug is spamming logs

asterisk -rx "pjsip set logger on"
# If it is ON accidentally, turn it OFF:
asterisk -rx "pjsip set logger off"

If your log file is massive:

# Example (adjust file name)
sudo truncate -s 0 /var/log/asterisk/full

Then fix the root cause (registration/auth loops, NAT mismatch, wrong identify/match, firewall blocks). Related troubleshooting articles: AMI connection issue resolution, PJSIP 401/403 auth failures, One-way audio root causes.

Most Common Cause #4: Backups and Old Archives

FreePBX backup jobs can silently create huge archives, especially if:

• recordings are included in backups
• backup retention is misconfigured
• backups are stored locally but never offloaded

Check common backup location:

sudo du -sh /var/spool/asterisk/backup 2>/dev/null
sudo ls -lh /var/spool/asterisk/backup 2>/dev/null | head

Safe cleanup: delete old backup archives by age (example: older than 30 days), but only after confirming you have valid external backups.

# Preview first
sudo find /var/spool/asterisk/backup -type f -mtime +30 -print | head

# Delete old archives
sudo find /var/spool/asterisk/backup -type f -mtime +30 -delete

Web Server Logs: NGINX/Apache Can Also Fill Disks

Depending on your setup you might have:

• /var/log/nginx
• /var/log/apache2 (Debian/Ubuntu)
• /var/log/httpd (RHEL/CentOS/Rocky)

sudo du -sh /var/log/nginx 2>/dev/null
sudo du -sh /var/log/apache2 2>/dev/null
sudo du -sh /var/log/httpd 2>/dev/null

If access logs are huge, truncate safely and then ensure logrotate is enabled.

After Cleanup: Restart Services Safely

Once you have freed space, restart key services so FreePBX can write state again:

# Asterisk
sudo systemctl restart asterisk

# Web server (pick the one you use)
sudo systemctl restart nginx
sudo systemctl restart apache2
sudo systemctl restart httpd

# Database (only if needed)
sudo systemctl restart mariadb
sudo systemctl restart mysql

Then confirm:

df -h
asterisk -rx "core show uptime"
asterisk -rx "core show channels"

Prevention: Make Disk Full a “Never Again” Event

If you implement retention + rotation + alerts, “disk full” becomes a controlled maintenance event, not an outage.

Recommended Alert Script (Simple, Works Everywhere)

Create a daily check that emails you when disk crosses a threshold. This is intentionally minimal and reliable.

# /usr/local/bin/check-disk.sh
#!/usr/bin/env bash
set -euo pipefail

THRESHOLD=85
MOUNT="/"

USED=$(df -P "$MOUNT" | awk 'NR==2 {gsub("%","",$5); print $5}')

if [ "$USED" -ge "$THRESHOLD" ]; then
  echo "ALERT: Disk usage on ${MOUNT} is ${USED}% on $(hostname) at $(date)"
  # Hook your mail/whatsapp/webhook here
fi

Add cron:

sudo crontab -e

# Run daily at 09:00
0 9 * * * /usr/local/bin/check-disk.sh

Common Mistakes That Make It Worse

Deleting random files in /var/lib/mysql (or database directory)

This can corrupt your DB. If DB is huge, diagnose and archive properly instead of deleting blindly.

Deleting log files that services still hold open

Prefer truncate -s 0 so the process keeps its handle and disk frees immediately.

Enabling SIP/PJSIP debug logging for days

Debug logs are meant for short windows. If you need long-term monitoring, reduce verbosity and rotate aggressively.

Related Guides

• Fetch & Clear Backend Service Logs (journalctl workflow)
• Ports Required for FreePBX + Asterisk (Firewall Guide)
• Wireshark Live Monitoring for SIP & RTP (Diagnose NAT / One-Way Audio)
• Registration Auth Failures (401/403) — Fix Root Cause (Stops Log Flooding)

Key Takeaway

FreePBX disk full issues are usually predictable: recordings, logs, voicemail, and backups. Fix it fast by freeing safe space (logs/cache), then solve permanently with retention, rotation, and alerts.