🚨 crontab Error: 'no crontab for myuser' — Cause, Fix, and Troubleshooting Guide

Overview

no crontab for myuser is what crontab -l prints when the user you are asking about has no crontab file installed. It is a statement of fact, not an error condition: cron stores each user’s jobs in a per-user file under /var/spool/cron/ (/var/spool/cron/crontabs/ on Debian/Ubuntu), and that file does not exist for this user.

The message trips people up in three ways: they installed jobs as a different user than the one they are now listing; the crontab was cleared (often by an accidental crontab -r); or they are looking in the wrong place entirely because the jobs live in the system crontab (/etc/crontab, /etc/cron.d/), which crontab -l never shows.

You will see it here:

$ crontab -l
no crontab for myuser

And when checking another user:

$ sudo crontab -l -u deploy
no crontab for deploy

Symptoms

• crontab -l prints no crontab for <user> and lists nothing.
• A cron job you believe you installed does not run and does not appear in the listing.
• The job works under one login but “disappears” under another.
• crontab -l is empty, yet cron jobs clearly still execute (they live in /etc/cron.d or /etc/crontab).
• Right after running crontab -r by mistake, all jobs are gone.

Common Root Causes

1. No crontab was ever installed for this user

The simplest case — you have not run crontab -e (or loaded a file) as this user yet, so no spool file exists.

sudo ls -l /var/spool/cron/crontabs/ 2>/dev/null || sudo ls -l /var/spool/cron/

total 4
-rw------- 1 root crontab 1024 Jul 10 09:12 root

Only root has a file here; myuser has none — hence no crontab for myuser.

2. You are listing the wrong user

You installed jobs as root (or via sudo) but are now listing as myuser, or vice versa. Each user has a separate crontab.

whoami
crontab -l              # current user
sudo crontab -l -u root # root's crontab

3. The crontab was cleared or lost

crontab -r removes the entire crontab with no confirmation. It sits one key away from crontab -e on most keyboards. A reimaged host or migrated user account loses the spool file too.

4. The jobs are in the system crontab, not a user crontab

crontab -l only reads per-user spool files. Jobs defined in /etc/crontab or dropped into /etc/cron.d/ are read directly by cron and never appear in crontab -l. Those entries have an extra user field.

cat /etc/crontab
ls -l /etc/cron.d/

17 *  * * *  root  cd / && run-parts --report /etc/cron.hourly
30 3  * * *  deploy /opt/jobs/nightly.sh

The deploy job runs, but sudo crontab -l -u deploy still says no crontab for deploy because it lives in /etc/cron.d.

5. Running under a service account or in a container

In containers and under sudo -u, whoami may not be who you think. crontab -l targets the effective user, which may have no crontab.

How to Diagnose

Step 1 — Confirm who you are and whose crontab you are reading.

id -un
crontab -l 2>&1

myuser
no crontab for myuser

Step 2 — Check the other likely owners. The jobs may belong to root or a deploy user.

for u in root deploy myuser www-data; do
  echo "== $u =="; sudo crontab -l -u "$u" 2>&1 | head -3
done

== root ==
0 6 * * * /opt/jobs/report.sh
== deploy ==
no crontab for deploy
== myuser ==
no crontab for myuser
== www-data ==
no crontab for www-data

Here the jobs actually live in root’s crontab.

Step 3 — Look at the spool directory and system crontab directly.

sudo ls -l /var/spool/cron/crontabs/ 2>/dev/null; sudo ls -l /var/spool/cron/ 2>/dev/null
cat /etc/crontab; ls -l /etc/cron.d/

Step 4 — Confirm what cron actually ran to find where a live job is defined.

journalctl -t CRON --since '-1d' | grep -i 'CMD' | tail

Jul 12 03:30:01 host CRON[9921]: (deploy) CMD (/opt/jobs/nightly.sh)

The (deploy) job is running from /etc/cron.d, even though crontab -l -u deploy reports none.

Fixes

Create a crontab for the user interactively.

crontab -e

Add a line, save, and cron installs the spool file. crontab -l will now list it.

Install a crontab from a version-controlled file (repeatable).

cat > /opt/jobs/myuser.cron <<'EOF'
PATH=/usr/local/bin:/usr/bin:/bin
0 6 * * * /opt/jobs/report.sh >> /var/log/report.log 2>&1
EOF
crontab /opt/jobs/myuser.cron
crontab -l

PATH=/usr/local/bin:/usr/bin:/bin
0 6 * * * /opt/jobs/report.sh >> /var/log/report.log 2>&1

Target the right user explicitly so you stop editing the wrong one:

sudo crontab -e -u deploy
sudo crontab -l -u deploy

Recover from an accidental crontab -r. There is no undo, but reinstall from your version-controlled copy. Cron often leaves the last-installed content nowhere, so keep the source file in git. If you have a backup of the spool file:

sudo cp /var/backups/crontabs/myuser /var/spool/cron/crontabs/myuser
sudo chown myuser:crontab /var/spool/cron/crontabs/myuser
sudo chmod 600 /var/spool/cron/crontabs/myuser

Use the system crontab for system-owned jobs — put them in /etc/cron.d/ with an explicit user field, and stop expecting crontab -l to show them:

# /etc/cron.d/nightly
30 3 * * * deploy /opt/jobs/nightly.sh >> /var/log/nightly.log 2>&1

What to Watch Out For

• crontab -r deletes everything with no prompt and no confirmation. Alias it to crontab -i (-i prompts) or avoid it entirely; always keep the source in git and install with crontab file.
• User crontabs and the system crontab (/etc/crontab, /etc/cron.d/*) are separate worlds. crontab -l only shows the former — if a job runs but isn’t listed, check the latter.
• /etc/cron.d/ and /etc/crontab lines have a user field between the schedule and the command; per-user crontabs do not. Mixing the formats silently breaks the job.
• Use crontab -u <user> (as root) instead of su-ing around; it is explicit about which crontab you touch.
• On Debian/Ubuntu the spool path is /var/spool/cron/crontabs/; on RHEL/CentOS it is /var/spool/cron/. Check the right one for your distro.

Related Guides

• Cron Error: ‘(CRON) error (grandchild #NNNN failed with exit status 1)’
• Cron Error: ‘(CRON) info (No MTA installed, discarding output)’
• AI-Assisted Cron and Scheduled Job Cleanup