Since upgrading my user's crontab has been wiped out. This is not the first time this has happened this year and it's a pain restoring it each time.

I'd like to be able to back up the crontab for my user but for that I need to know where it's stored.

  • 6
    it would be nice if someone could also give a reason WHY it's wiped out Nov 13 '12 at 14:52
  • 1
    @WalterTross Yeah it's quite annoying. I would guess it's a side-effect of updating the cron package but I agree - it's not something that should happen.
    – Oli
    Nov 13 '12 at 16:04
  • Uh, I don't that user cron's get wiped per cron package upgrade!
    – pl1nk
    Mar 28 '13 at 12:15
  • @pl1nk I've no idea what's wiping it out but it does keep happening. Ghost in the machine, I guess.
    – Oli
    Mar 28 '13 at 12:19
  • 1
    Just want to mention that there are instructions here about how to reconstruct an accidentally deleted crontab using logs: superuser.com/questions/384109/crontab-deleted It's not really what you were asking but it might be of use to someone.
    – msouth
    Dec 9 '16 at 16:01

Actually, it's not recommended to handle those files by hand. Per crontab man page:

Each user can have their own crontab, and though
these are files in /var/spool/cron/crontabs, they are not
intended to be edited directly.

Files under /var/spool are considered temporary/working, that's why they probably get deleted during an upgrade, though a closer look at the cron package's upgrade scripts may shed some light on this.

Anyway, it's always a good practice to back up your cron entries or keep them in a file in your home directory.

I assume you're using crontab -e to create crontab files on the fly. If so, you can get a "copy" of your crontab file by doing crontab -l. Pipe that to a file to get a "backup":

crontab -l > my-crontab

Then you can edit that my-crontab file to add or modify entries, and then "install" it by giving it to crontab:

crontab my-crontab

This does the same syntax checking as crontab -e.

  • 13
    crontab -l is easier than going through /var/spool/cron/crontabs/$USER mostly because of the bizarre permissions on that file.
    – Oli
    Nov 13 '12 at 16:02
  • 1
    The iptables-save of cron. Nice... Jul 18 '15 at 0:10
  • 7
    Perhaps we should put a crontab to automatically back itself up >:)? Jul 27 '15 at 16:28
  • 4
    Poking through /var/spool/cron/crontabs is handy when you want to curate or examine crontabs from multiple users.
    – dhasenan
    Aug 6 '16 at 14:59
  • 1
    When investigating mysteries on a server you aren't familiar with, it is common to sudo grep -rHin "$string" /etc/cron* (where string might be a command like docker, lftp, iptables, etc. It's a good idea to check user crontabs also. That's what lead me to this Q&A. sudo grep -rHin "$string" /etc/cron* /var/spool/cron* Dec 29 '17 at 17:10

Its stored inside /var/spool/cron/crontabs folder under username.


I finally found out why my crontabs and Postfix installation kept breaking after boot. It's a really stupid reason but...

I had /var/spool mounted as a tmpfs RAM-drive.

Sounds idiotic and it is, but I had followed one of the old SSD-tweaks to lengthen the life of my SSD. In doing so, I blindly mounted /tmp, /var/tmp and /var/spool as tmpfs without thinking of the repercussions. I thought /var/spool was like /proc/ or /run/ and that it was only useful for the duration of the session. I was clearly wrong.

  • 11
    It should be safe to mount /tmp as tmpfs, but not /var/tmp or /var/spool. /tmp is used for temporary storage that may be lost upon reboot. /var/tmp is used for temporary storage that will remain after a reboot. And as you've discovered, /var/spool is for data to be processed, which will also remain after a reboot. Jun 30 '14 at 5:42
  • 2
    See pathname.com/fhs/2.2/fhs-5.15.html Jun 30 '14 at 5:43
  • 2
    Note also that write count is no longer an issue with modern SSDs. Jun 30 '14 at 5:45

To list all cron jobs from all users in your system:

for user in $(cut -f1 -d: /etc/passwd)
  echo $user
  crontab -u $user -l

An alternative to your issue would be to place them in cron.d folder and specify the appropriate user per cron as in example:

00 01 * * * user /home/user/user-script.sh
  • if you're recovering the crontab from another drive, this will not work because crontab -u is running from your current system.
    – JVE999
    Oct 9 '14 at 21:38
  • While I suppose that is a one-liner in that it fits in less than 80 characters and is somewhat readable, I generally like to put code in a format such that a person can either copy-paste or put it in a script (and, in a script, this would not be one line of code). Suggesting edit... Jul 18 '15 at 0:14
  • Also, I was about to turn it into a while read user loop, to handle the case where the username contains spaces, but apparently that's not an issue. Very limited set of username characters. Jul 18 '15 at 0:24

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.