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, 2012 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, 2012 at 16:04
  • Uh, I don't that user cron's get wiped per cron package upgrade!
    – pl1nk
    Mar 28, 2013 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, 2013 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, 2016 at 16:01

4 Answers 4


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.

  • 16
    crontab -l is easier than going through /var/spool/cron/crontabs/$USER mostly because of the bizarre permissions on that file.
    – Oli
    Nov 13, 2012 at 16:02
  • 2
    The iptables-save of cron. Nice... Jul 18, 2015 at 0:10
  • 13
    Perhaps we should put a crontab to automatically back itself up >:)? Jul 27, 2015 at 16:28
  • 5
    Poking through /var/spool/cron/crontabs is handy when you want to curate or examine crontabs from multiple users.
    – dhasenan
    Aug 6, 2016 at 14:59
  • 3
    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, 2017 at 17:10

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

  • Thanks, I realize this is an old answer. It's at var/spool/cron/tabs/<user> on a recent OpenSuse Tumbleweed installation. Feb 19 at 7:56

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.

  • 13
    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, 2014 at 5:42
  • 2
    See pathname.com/fhs/2.2/fhs-5.15.html Jun 30, 2014 at 5:43
  • 2
    Note also that write count is no longer an issue with modern SSDs. Jun 30, 2014 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, 2014 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, 2015 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, 2015 at 0:24

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .