When the filesystem holding /var/spool/postfix runs out of bytes, all mail I/O stops. The queue manager cannot write new queue files, cleanup cannot inject messages, and pickup cannot move mail from maildrop into incoming. Postfix may still listen on port 25 and accept TCP connections, but every accepted message eventually fails with “No space left on device” or is rejected by the SMTP server’s free-space check.

This is a cliff-edge failure with no graceful degradation. The master process may also fail to update its PID file at /var/spool/postfix/pid/master.pid, leaving stale state that complicates recovery.

The byte-exhaustion scenario has a sibling that produces the identical error string: inode exhaustion. A partition can have 50% free bytes but zero free inodes, and Postfix reports “No space left on device” either way. Run both df -h and df -i first; the fixes are completely different.

What this means

Every message is a queue file. Every queue operation (accepting, delivering, deferring, bouncing) is a file write, rename, or unlink. When the partition hits ENOSPC, all of these fail simultaneously.

Postfix has a built-in safety valve: the queue_minfree parameter. Even with its default value of 0, Postfix 2.1+ enforces a minimum free-space floor of 1.5 * message_size_limit. With the default message_size_limit of 10240000 bytes (10 MB), the effective floor is approximately 15 MB. When free space drops below that threshold, the SMTP server rejects MAIL FROM and logs:

warning: not enough free space in mail queue: X bytes < 1.5*message size limit

This check covers byte-level free space only. It does not protect against inode exhaustion. It also does not account for space consumed by other directories sharing the partition. If /var/log and the queue share /var, a log spike can fill the partition and halt mail even though the queue itself is modest.

flowchart TD
    A["Postfix: No space left on device"] --> B{"df -h full?"}
    B -->|"Yes"| C["Byte exhaustion"]
    B -->|"No, but df -i full"| D["Inode exhaustion"]
    B -->|"Both have space"| E["Check dmesg for FS Errors"]
    C --> F["Large attachments,
log growth, shared partition"]
    D --> G["Millions of tiny
queue files"]

Common causes

CauseWhat it looks likeFirst thing to check
Deferred queue with large attachmentsdu -sh /var/spool/postfix/deferred/ shows GBfind /var/spool/postfix/deferred -type f -size +10M | wc -l
Log files on the same partition/var/log/ dominates disk usage; queue is smalldu -sh /var/log/ /var/spool/postfix/
Unbounded queue growth from delivery failureBoth deferred and active queues large; delivery stalledpostqueue -p | tail -1
Shared /var with other servicesDatabase files, package cache, or app data consuming spacedu -sh /var/\*/ | sort -rh | head
Reserved blocks on ext4df shows partition full but du disagreestune2fs -l <device> | grep Reserved

Quick checks

All read-only and safe during an active incident.

# Check byte usage on the queue filesystem
df -h /var/spool/postfix

# Check inode usage on the same filesystem
df -i /var/spool/postfix

# Disk usage by queue subdirectory
du -sh /var/spool/postfix/*/ | sort -rh

# Disk usage within deferred hash subdirectories (deferred/0/, deferred/1/, ...)
du -sh /var/spool/postfix/deferred/*/ | sort -rh

# Count files per queue
for q in maildrop incoming active deferred hold corrupt; do
  echo -n "$q: "; find /var/spool/postfix/$q -type f 2>/dev/null | wc -l
done

# Check what else is consuming the partition
du -sh /var/*/ 2>/dev/null | sort -rh | head -15

# Look for the Postfix free-space rejection in logs
# Log path may be /var/log/maillog on RHEL/CentOS
grep "not enough free space" /var/log/mail.log | tail -5

# Look for ENOSPC write errors
grep -i "No space left on device" /var/log/mail.log | tail -10

# Current queue_minfree and message_size_limit values
postconf -h queue_minfree message_size_limit

# Current queue depth summary
postqueue -p | tail -1

How to diagnose it

  1. Byte vs inode exhaustion. If df -h shows >90% but df -i is fine, this is byte exhaustion. If df -i shows >90% with free bytes remaining, it is inode exhaustion (the fix is different). If both have headroom, check dmesg for filesystem or hardware errors.

  2. Find the space consumer. Run du -sh /var/*/ 2>/dev/null | sort -rh | head -15. If /var/spool/postfix dominates, the queue is the problem. If /var/log dominates, log growth is crowding out the queue on a shared partition.

  3. Drill into the queue. Deferred is the usual suspect because it accumulates failed-delivery mail. Deferred uses hashed subdirectories by default (hash_queue_names = deferred, defer, hash_queue_depth = 1), so also run du -sh /var/spool/postfix/deferred/*/.

  4. Check message profile. Count oversized messages: find /var/spool/postfix/deferred -type f -size +10M | wc -l. A handful of large attachments can consume surprising space.

  5. Check the delivery failure pattern. grep 'status=deferred' /var/log/mail.log | tail -30. If all mail to one destination is deferred, a single unreachable destination may be filling the queue.

  6. Verify the free-space threshold. Run postconf -h queue_minfree message_size_limit. If free space is below 1.5 * message_size_limit, the SMTP server is actively rejecting new mail.

Metrics and signals to monitor

SignalWhy it mattersWarning sign
df -h on queue filesystemByte exhaustion halts all I/O with no graceful degradation>80% warning, >90% critical
df -i on queue filesystemInode exhaustion produces the same ENOSPC error but needs a different fix>80% warning, >90% critical
Deferred queue file countGrowing deferred queue is the leading indicator of disk pressureSustained growth >100 files/hour
Deferred queue byte sizeLarge attachments in deferred consume bytes faster than small messagesGrowth trend over hours
Growth rate (runway)Linear projection of time-to-exhaustionProjected to hit 90% within 24 hours
Free-space rejection log rateSMTP server rejecting MAIL FROM means queue_minfree threshold hitAny occurrence
Total queue files across all sub-queuesCombined queue depth predicts both disk and inode pressureTrending upward over days

Fixes

Immediate: clear disk space

The fastest relief is removing the largest consumers. Choose carefully: deleting the wrong queue files means permanent mail loss.

Delete the entire deferred queue (destructive):

# WARNING: This permanently deletes ALL deferred messages.
# Verify you are willing to lose every undelivered message before running.
postsuper -d ALL deferred

Use this when the deferred queue contains only spam, backscatter, or mail that is acceptable to lose. The command is slow on very large queues because it processes files individually.

Delete specific messages by queue ID:

# Delete a single message by queue ID
postsuper -d QUEUEID

# Delete messages from MAILER-DAEMON (backscatter)
# Step 1: identify the queue IDs
postqueue -p | grep 'MAILER-DAEMON' | awk '{print $1}' | tr -d '*!'
# Step 2: review the list, then delete via stdin
postqueue -p | grep 'MAILER-DAEMON' | awk '{print $1}' | tr -d '*!' | postsuper -d -

Purge orphaned temporary files (safe):

# Remove temporary files left by crashes or unclean shutdowns
postsuper -p

Run this after any unclean shutdown to clean up files no longer referenced by any queue entry.

Hold mail instead of deleting (reversible, but does not free space):

# Move all deferred messages to the hold queue
postsuper -h ALL deferred

# Release them later after space is recovered
postsuper -H ALL deferred

Held messages stop consuming delivery attempts but still occupy disk space. Use this to organize cleanup, not as a space-recovery step.

Clear logs if they share the partition:

If /var/log is on the same partition and is the space consumer, rotate or truncate logs.

# Check log sizes
du -sh /var/log/* | sort -rh | head
# Force log rotation (path varies by distribution)
logrotate -f /etc/logrotate.d/syslog

Root cause: address why mail is accumulating

Clearing space is temporary if the underlying cause persists.

Unreachable destination. A single slow or blocking destination fills the deferred queue. Identify it:

grep 'status=deferred' /var/log/mail.log | awk -F'to=<|>' '{print $2}' | cut -d@ -f2 | sort | uniq -c | sort -rn | head

If one domain dominates, reduce its concurrency or investigate the block. See the destination concurrency limit guide and the connection timed out guide.

Large attachment backlog. Messages with large attachments consume disproportionate bytes. If your system regularly handles large attachments, consider reducing message_size_limit to cap the maximum message size and prevent a few messages from dominating disk usage.

Backscatter or bounce loop. Bounces to forged senders generate MAILER-DAEMON messages that fill the queue. Check for double-bounce patterns: grep 'MAILER-DAEMON' /var/log/mail.log | tail -20. See the backscatter storm guide and the double-bounce loop guide.

Content filter backpressure. If a content filter (Amavis, Rspamd) is slow or stopped, mail piles up in the incoming queue. Check filter health and response times separately. See the content_filter backpressure guide.

Structural: isolate the queue partition

If logs, databases, or application data share /var with the Postfix queue, a log spike or package cache growth can fill the partition and halt mail even though the queue is healthy. The long-term fix is to put /var/spool/postfix on its own partition, LVM volume, or filesystem.

After moving the queue directory to a new filesystem, run postsuper -s to rebuild the queue file structure. Queue file names are derived from inode numbers, and moving to a new filesystem invalidates those associations. Run postsuper -s repeatedly until it reports no more changes.

Prevention

  • Isolate the queue filesystem. Put /var/spool/postfix on its own partition or volume so a full log directory or package cache cannot take Postfix down.
  • Monitor both bytes and inodes. Postfix creates one file per queued message. Inode exhaustion produces the same “No space left on device” error as byte exhaustion but requires a completely different fix.
  • Alert on runway, not just level. A partition at 70% growing at 5% per hour will be full in 4 hours. Set warning at >80% and critical at >90%, but also alert when the trend projects exhaustion within 24 hours.
  • Set queue_minfree explicitly. The default 0 still enforces the 1.5x floor, but an explicit value gives you a documented safety margin. Consider several hundred MB to ensure Postfix rejects mail before the filesystem is dangerously full.
  • Watch for XFS inode limits. XFS with default mkfs.xfs options caps inodes at a percentage of volume space. On a large partition hosting millions of small queue files, this can cause premature exhaustion. Use -i maxpct=NN at filesystem creation time to raise the limit.
  • Review stale deferred entries. The default maximal_backoff_time is 4000 seconds (about 1.1 hours), but messages can remain in the deferred queue for days if delivery keeps failing. Periodically review and expire stale deferred entries.

How Netdata helps

  • Filesystem space and inode utilization charts update per second on every mounted partition, including /var/spool/postfix. During a disk-fill incident, this shows the growth rate and exact moment of exhaustion.
  • The Postfix collector tracks queue depth by sub-queue (incoming, active, deferred, hold, corrupt, maildrop). Correlating deferred queue growth with disk consumption identifies whether the queue is the space consumer or whether another directory on the partition is to blame.
  • ML-based anomaly detection on disk usage metrics flags unusual growth rates early. For this failure mode, growth rate is the strongest leading indicator because the cliff arrives hours after the trend becomes visible.
  • Disk I/O metrics on the underlying device help distinguish a storage throughput bottleneck from a space problem.