postfix check warnings: configuration drift and permission problems

postfix check walks the Postfix file tree, verifies ownership, group, and permission rules (defined in the postfix-files manifest), and reports drift. It exits non-zero only on fatal problems such as invalid configuration; permission and ownership drift is reported as warnings with a zero exit status. It does not stop or restart the running master. Safe to run in production at any time, which also makes the warnings easy to ignore.

What this means

The expected filesystem state is defined in postfix-files, which ships with the package and encodes ownership, group, and permission bits for every file and directory Postfix touches. When reality diverges from the manifest, you get a warning.

The warnings fall into distinct categories:

• Ownership and permission drift. Queue directories, daemon binaries, or the spool root have wrong owner, group, or mode bits. Common triggers: package updates that reset permissions, manual chown/chmod operations, filesystem restores that lose metadata, container builds that bake in incorrect ownership.
• Setgid binary problems. postdrop and postqueue must be owned by group postdrop with the setgid bit set. Without this, local mail submission via sendmail fails because postdrop cannot write to the maildrop queue directory. The failure shows up at runtime as mail_queue_enter: create file maildrop/...: Permission denied.
• Configuration inconsistency. Undefined parameters referenced in master.cf (common with distro-packaged templates from Virtualmin or Plesk), compatibility_level mismatches that log warnings about changed defaults, and parameters whose values depend on other parameters that have drifted.
• MAC denials (invisible to postfix check). SELinux or AppArmor policies blocking Postfix daemons from accessing files, sockets, or ports. These appear in /var/log/audit/audit.log or kernel logs, not in mail.log. postfix check has no visibility into MAC policy.

The master keeps running through all of these. The risk is subtle, hard-to-diagnose failures: local mail stuck in maildrop because postdrop lost its setgid bit, TLS handshakes failing because compatibility defaults are stale, queues growing because a MAC policy update blocked access to a map file.

flowchart TD
    A["postfix check returns warnings"] --> B{Category?}
    B -->|Permission or ownership| C["Check postfix-files manifest"]
    B -->|Setgid binary| D["Verify postdrop/postqueue group and mode"]
    B -->|Undefined parameter| E["Define in main.cf or remove from master.cf"]
    B -->|compatibility_level| F["Set level explicitly, then reload"]
    B -->|Clean but mail broken| G["Check audit.log for MAC denials"]
    C --> H["Run postfix set-permissions"]
    D --> H
    E --> I["postfix reload or restart"]
    F --> I
    G --> J["Set boolean or generate policy"]

Common causes

Quick checks

All read-only. Safe for production.

# Run the check itself
postfix check 2>&1

# Verify queue directory permissions
# maildrop: 1730 (drwx-wx--T) on Debian-family; upstream manifest declares 730. public: drwx--x--- (710)
ls -ld /var/spool/postfix/maildrop/ /var/spool/postfix/public/

# Check setgid binaries (group execute should show 's', not 'x')
ls -l /usr/sbin/postdrop /usr/sbin/postqueue 2>/dev/null || ls -l /usr/bin/postdrop /usr/bin/postqueue

# List files in the spool not owned by postfix or root
find /var/spool/postfix -type f ! -user postfix ! -user root 2>/dev/null | head -20

# Check for setuid/setgid files in the queue (should be none)
find /var/spool/postfix -type f -perm /6000 2>/dev/null

# Show current compatibility_level
postconf -h compatibility_level

# Check for undefined parameter warnings during config expansion
postconf -n 2>&1 | grep -i warning

# Look for SELinux AVC denials related to postfix
ausearch -m avc --start recent 2>/dev/null | grep -i postfix | tail -20

# Verify master PID file consistency
cat /var/spool/postfix/pid/master.pid 2>/dev/null && ps -p "$(cat /var/spool/postfix/pid/master.pid)" -o pid,comm,lstart

How to diagnose

1. Run postfix check and capture all output. Warnings are prefixed with postfix/postfix-script: warning:. Categorize into ownership, setgid, directory, or configuration issues.

2. For ownership and permission warnings, compare reported paths against postfix-files. The upstream manifest declares maildrop mode 730 and public mode 710, both owned by $mail_owner:$setgid_group; Debian-family systems commonly install maildrop with the sticky bit as mode 1730 (drwx-wx--T).

3. For setgid binary warnings, verify that postdrop and postqueue are owned by group postdrop with the setgid bit set. In ls -l output, the group execute position shows s, not x.

4. For undefined parameter warnings, grep master.cf for the references. Typical offenders are mua_sender_restrictions, mua_client_restrictions, and mua_helo_restrictions, leftover template parameters from some distro packages. They appear during both postfix check and postconf -n.

5. For compatibility_level warnings, check the current value. Postfix 3.0+ logs warnings when running with backwards-compatible defaults. Below level 1, append_dot_mydomain changes from yes to no, the master.cf chroot default changes from y to n, and smtpd_relay_restrictions falls back to empty. Below 3.6, TLS fingerprint digests switch from MD5 to SHA256 and relay restriction ordering changes. Review COMPATIBILITY_README for the full list at each threshold.

6. If postfix check is clean but mail is broken, check for MAC denials. SELinux AVC denials for Postfix daemons are logged to /var/log/audit/audit.log, not mail.log. AppArmor denials appear in kernel logs or the same audit log depending on distribution. This is the most commonly missed path because operators expect all Postfix problems in mail.log.

7. Determine whether reload is sufficient or a full stop/start is needed. Most main.cf parameters take effect after postfix reload. However, inet_interfaces changes require a full stop and start. The master daemon does not pick up main.cf changes automatically, and master.cf changes are never applied without an explicit reload or restart. When uncertain, postfix stop && sleep 2 && postfix start is safer than reload because long-running daemons can retain cached config.

Metrics and signals to monitor

Fixes

Permission and ownership drift

The safest fix is postfix set-permissions, which restores ownership and permissions per the postfix-files manifest.

# Restore all Postfix file permissions from the manifest (non-disruptive)
postfix set-permissions

# Verify
postfix check

On Debian-based systems, postfix set-permissions may report warnings for files that the Debian package layout does not include. If warnings persist after set-permissions, fix specific paths manually.

For targeted manual fixes. These commands change ownership and permissions on live queue directories. Verify the paths match your installation before running.

# Fix spool root ownership
chown root:root /var/spool/postfix

# Fix queue directory ownership and permissions
chown postfix:postdrop /var/spool/postfix/maildrop
chmod 1730 /var/spool/postfix/maildrop
chown postfix:postdrop /var/spool/postfix/public
chmod 710 /var/spool/postfix/public

Setgid binary problems

# Fix postdrop and postqueue group ownership and setgid bit
chgrp postdrop /usr/sbin/postdrop /usr/sbin/postqueue
chmod g+s /usr/sbin/postdrop /usr/sbin/postqueue

# Verify (group execute should show 's')
ls -l /usr/sbin/postdrop /usr/sbin/postqueue

The binary path varies by distribution: /usr/sbin/postdrop on Debian/Ubuntu, /usr/bin/postdrop on others. Check with command -v postdrop.

In containers or systemd units with NoNewPrivileges=true, the setgid bit on postdrop does not take effect, preventing local mail submission. This is a kernel security feature, not a Postfix bug. If your deployment uses NoNewPrivileges, local mail submission via sendmail may need an alternative submission path.

Undefined parameters in master.cf

Either define the parameters in main.cf or remove the references from master.cf:

# Option 1: Define the parameters as empty (quick fix for template leftovers)
postconf -e 'mua_sender_restrictions ='
postconf -e 'mua_client_restrictions ='
postconf -e 'mua_helo_restrictions ='

# Option 2: Remove the references from master.cf (cleaner)
# Edit /etc/postfix/master.cf and remove or comment the offending lines

After either fix, run postfix check to confirm the warnings are gone, then postfix reload.

compatibility_level warnings

Set the compatibility level explicitly to silence the warnings and adopt current defaults:

# Check current level
postconf -h compatibility_level

# Set to your target level and reload
postconf -e compatibility_level=3.6
postfix reload

Review COMPATIBILITY_README before raising the level. Changed defaults may affect TLS fingerprint algorithms, relay restriction ordering, and chroot behavior. Test in staging first.

SELinux denials

If audit.log shows AVC denials for Postfix, review them first to confirm they are legitimate access needs, not an attack or misconfiguration.

# Search for recent Postfix AVC denials
ausearch -m avc --start recent | grep -i postfix

# Generate a custom policy module (review the .te file before applying)
audit2allow -a -M postfixCustom
semodule -i postfixCustom.pp

For Postfix needing write access to mail spool directories, the SELinux boolean postfix_local_write_mail_spool (enabled by default on Fedora/RHEL policies) may resolve the issue without a custom policy.

# Check current setting
getsebool postfix_local_write_mail_spool

# Enable persistently
setsebool -P postfix_local_write_mail_spool 1

Debian and Ubuntu do not ship an active AppArmor profile for Postfix by default (the apparmor-profiles package only ships postfix-* extras). If you use one, it lives in /etc/apparmor.d/ and denials appear in kernel logs (dmesg or /var/log/kern.log).

Prevention

• Run postfix check nightly via cron, then grep mail.log for reject|warning|error|fatal|panic. Alert on any non-empty output from either step.
• Run postfix check after every package update. Package updates are the most common source of permission drift, especially for setgid binaries where the package manager may reset group or mode bits.
• Track file permissions in configuration management. If you manage Postfix with Ansible, Puppet, or Chef, declare the expected file ownership and mode bits so drift is corrected on the next run.
• Set compatibility_level explicitly in main.cf. Never leave it at the default. This prevents surprise behavior changes and silences compatibility warnings that clutter logs.
• Document reload vs restart per parameter in your runbooks. At minimum: inet_interfaces requires stop/start, master.cf service additions require reload. Prefer postfix stop && sleep 2 && postfix start when you need certainty that cached config is fully cleared.
• Monitor audit.log for MAC denials alongside mail.log. SELinux and AppArmor denials for Postfix are invisible in standard mail logging. Include audit.log scanning in Postfix health checks, especially after OS-level policy updates.

How Netdata helps

• Per-second queue depth metrics let you correlate a postfix check warning with immediate changes in maildrop or deferred queue size, confirming whether a permission problem is actually affecting mail flow or is purely cosmetic.
• Mail log parsing surfaces postdrop permission errors, bounce rate spikes, and deferral patterns, so you see the runtime impact of configuration drift without manually grepping logs.
• Anomaly detection on queue growth rates catches the slow accumulation that follows a silent setgid failure or a stale config value, even when absolute thresholds have not been crossed.
• Filesystem monitoring (inodes, disk space, file descriptors) provides the surrounding context that distinguishes a Postfix permission problem from system-level resource exhaustion.

Related guides

• How Postfix actually works in production: a mental model for operators
• Postfix master process not running: the whole MTA is down
• Postfix monitoring checklist: the signals every production mail server needs
• Postfix monitoring maturity model: from survival to expert