Crontab -e Shows "No crontab for user" Then Opens Empty File

Yes, this message is annoying. But it's actually not an error.

You type crontab -e as a regular user, and you see:

no crontab for username - using an empty one

Then the editor opens a blank file. You save it. Nothing happens. The message comes back next time. I know this tripped me up the first time too when I started with Linux. The fix is simple: add at least one valid cron entry before saving.

The Quick Fix

1. Open the crontab editor: crontab -e
2. Add a dummy entry (this tells cron you actually want a crontab file):

# This is my first cron job - it runs every Monday at 5am
0 5 * * 1 echo "Hello from cron" >> /tmp/cron_test.log 2>&1

3. Save and exit. In vim, that's :wq. In nano, it's Ctrl+X, then Y, then Enter.
4. Run crontab -l to confirm your entry is saved. You should see the line you added.

Now the message "no crontab for user" will not appear again. If you want to delete the dummy job later, just remove that line from the file.

Why This Happens

Cron stores each user's jobs in a separate file under /var/spool/cron/crontabs/ (on most Linux distros). When you run crontab -e for the first time, that file doesn't exist yet. So cron says "no crontab for user" and creates a temporary empty file for you to edit.

The trick is: if you save an empty file, cron removes the temporary file (because it sees no valid entries). Next time you run crontab -e, the same routine repeats. You're stuck in a loop.

By adding a valid entry (even a comment line works on some systems, but a real job is safer), cron creates the actual file in /var/spool/cron/crontabs/. Now the message goes away.

Less Common Variations of the Same Issue

1. Crontab file disappears after reboot

If your crontab file is in /etc/cron.d/ instead of the user's spool, you might see similar behavior. The fix: use crontab -e as the user, not root, and always add a real entry before saving.

2. Permission problems on /var/spool/cron/crontabs/

On shared hosting or old systems, the spool directory might have wrong permissions. Output like crontab: can't change directory to '/var/spool/cron/crontabs': Permission denied tells you the real problem. Fix with sudo chmod 1733 /var/spool/cron/crontabs (the sticky bit is important).

3. Using an editor that doesn't save correctly

If you use a GUI editor like gedit or nano with a backup file, cron might reject the file. Always use a plain-text editor in terminal mode. I've seen this happen with gedit on Ubuntu 20.04.

4. The "crontab: no crontab for root" situation

This is actually normal. Root's crontab is stored in /etc/crontab and /etc/cron.d/, not in the spool. Running crontab -e as root will still work, but the message is harmless. Just add a job and it goes away.

Prevention for Next Time

Once you have a working crontab, don't delete the last entry without adding another one. Here's the rule:

• Always have at least one comment or job in your crontab file. If you want to disable all jobs, add a line like # DISABLED instead of removing everything.
• Test your syntax with crontab -l after saving. If you see no output, your file was rejected.
• Use a cron tester like crontab.guru to double-check your schedule before adding.

One more thing: if you're new to cron, remember that the six fields are: minute, hour, day of month, month, day of week, command. The example above (0 5 * * 1) means 5:00 AM every Monday. The command writes to a log file so you can confirm it ran.

That's it. No magic. Just a quirk of how cron handles first-time users. Next time you see that message, you'll know exactly what to do.