🚨 Cron Error: '(CRON) info (No MTA installed, discarding output)' — Cause, Fix, and Troubleshooting Guide

Overview

(CRON) info (No MTA installed, discarding output) is not an error in your job — it is cron telling you that your job produced output on stdout or stderr, and cron wanted to email that output to the job’s owner, but there is no Mail Transfer Agent (postfix, sendmail, msmtp, exim) installed to send the mail. So cron threw the output away.

Cron’s default behavior is to capture anything a job prints and mail it to the user (or to MAILTO). On minimal servers and containers there is usually no MTA, so every job that prints anything triggers this line. It is info, not error — the job may have succeeded. The real problem is twofold: your job is noisier than it should be, and any output it produces (including error messages you would want to see) is being silently discarded.

You will see this in the log right after the job runs:

Jul 12 06:00:01 host CRON[4821]: (myuser) CMD (/opt/jobs/report.sh)
Jul 12 06:00:01 host CRON[4820]: (CRON) info (No MTA installed, discarding output)

If an MTA is present but delivery has a hiccup, you get a different, related line where cron did try to mail:

Jul 12 06:00:01 host CRON[4820]: (root) MAIL (mailed 1 byte of output but got status 0x004b)

That status 0x004b is the MTA’s exit status packed by cron — the mail submission failed downstream.

Symptoms

• journalctl -t CRON shows (CRON) info (No MTA installed, discarding output) after a CMD (...) line.
• Jobs run fine but you never see their output, including error text you need for debugging.
• Log spam: the message appears on every scheduled run of a chatty job.
• With an MTA present, MAIL (mailed N bytes of output but got status 0xNN) instead.
• /var/mail/myuser (or /var/spool/mail) does not exist or is empty even though jobs print output.

Common Root Causes

1. No MTA installed (the literal cause)

The host has no local mailer, so cron cannot deliver captured output.

command -v sendmail postfix msmtp exim4 2>/dev/null || echo "no MTA on PATH"
ls -l /usr/sbin/sendmail 2>/dev/null || echo "no /usr/sbin/sendmail"

no MTA on PATH
no /usr/sbin/sendmail

2. The job writes to stdout/stderr at all

Any output — a curl progress meter, an echo, a warning — is enough to trigger delivery. A silent, successful job never produces this line.

grep -nE 'echo|printf|curl [^-]|-v|--verbose' /opt/jobs/report.sh

3. MAILTO is unset or misconfigured

Cron defaults to mailing the job owner. If MAILTO is unset and no MTA exists, output is discarded; if MAILTO="" cron won’t attempt mail at all (which is a valid way to silence it).

4. MTA installed but delivery fails

An MTA is present but unconfigured (no relay host, no auth), so cron logs MAIL ... got status 0xNN. The output was captured and handed off, but the MTA rejected or bounced it.

journalctl -u postfix --since '-1h' | tail -20

How to Diagnose

Step 1 — Confirm which variant you have.

journalctl -t CRON --since '-1d' | grep -E 'No MTA|MAIL '

Jul 12 06:00:01 host CRON[4820]: (CRON) info (No MTA installed, discarding output)

No MTA installed = nothing to send with. MAIL (... got status 0x..) = an MTA exists but delivery failed.

Step 2 — See exactly what output the job produces. Redirect it to a file and read it — this is the output cron was discarding.

# In the crontab
0 6 * * * /opt/jobs/report.sh > /tmp/report.out 2>&1

cat /tmp/report.out

Warning: TLS certificate for example.com expires in 6 days
Report written to /opt/jobs/out/report-2026-07-12.csv

Here the job succeeded; the “output” is just a warning and a status line. Now you can decide whether to keep it (log it) or silence it.

Step 3 — Check whether an MTA exists and works.

command -v sendmail && echo "test" | sendmail -v myuser@example.com; echo "rc=$?"

No sendmail on PATH confirms the No MTA path.

Fixes

Pick based on whether you want the output kept or discarded.

Redirect output to a log file (recommended). Keep the output, stop cron trying to mail it. Cron only mails when output reaches the terminal it captures; redirecting it away removes both the log line and the discarding.

0 6 * * * /opt/jobs/report.sh >> /var/log/report.log 2>&1

Silence a job you truly don’t care about. Send both streams to /dev/null:

0 6 * * * /opt/jobs/report.sh > /dev/null 2>&1

Be deliberate — this also hides error messages. Prefer a log file unless the job is genuinely fire-and-forget.

Disable cron mail globally with MAILTO. At the top of the crontab:

MAILTO=""
0 6 * * * /opt/jobs/report.sh

An empty MAILTO tells cron not to attempt delivery, so the No MTA line stops even without redirecting.

Actually deliver the mail — install and configure a lightweight MTA. msmtp relays to an external SMTP server without running a full mail stack:

sudo apt-get install -y msmtp msmtp-mta
sudo tee /etc/msmtprc >/dev/null <<'EOF'
defaults
auth on
tls on
host smtp.example.com
port 587
from cron@example.com
user cron@example.com
password REDACTED
EOF

Then set a real recipient so job output arrives by email:

MAILTO=alerts@example.com
0 6 * * * /opt/jobs/report.sh

Fix an existing MTA that returns a bad status. If you saw MAIL (... got status 0xNN), the mailer is installed but failing — check its own logs and relay/auth config:

journalctl -u postfix -t postfix --since '-1h' | tail
postconf relayhost

What to Watch Out For

• Redirecting to a log file is almost always the right answer for automation: you keep the output, drop the noise, and never depend on a mail stack.
• > /dev/null 2>&1 hides real errors too. If the job later starts failing, you will have thrown away the message that explains why — log to a file instead.
• 2>&1 must come after the stdout redirect; 2>&1 > file sends stderr to the old stdout (the terminal) and only stdout to the file.
• MAILTO="" silences mail; MAILTO=someone@example.com requires a working MTA or you’ll get MAIL ... got status failures instead.
• This is an info line — do not assume the job failed. Read the discarded output before concluding anything; it is frequently just a harmless warning.

Related Guides

• Cron Error: ‘(CRON) error (grandchild #NNNN failed with exit status 1)’
• crontab Error: ‘no crontab for myuser’
• AI-Assisted Cron and Scheduled Job Cleanup