102

as many (most?) others, I edit my crontab via crontab -e, where I keep all routine operations such as incremental backup, ntpdate, various rsync operations, as well as making my desktop background christmas themed once a year. From what I've understood, on a fresh install or new user, this also automatically creates the file if it doesn't exist. However, I want to copy this file to another user, so where is the actual file that I'm editing?

If this varies between distros, I'm using Centos5 and Mint 17

Jarmund
  • 1,118

2 Answers2

119

The location of cron files for individual users is /var/spool/cron/crontabs/.
From man crontab:

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.

7ochem
  • 141
heemayl
  • 56,300
  • 14
    The key words there are "they are not intended to be edited directly", so this answer is incomplete without Celada's command below, which provides a safer answer to the "copy to another user" portion of the question. If people get in the habit of directly editing crontabs without submitting them through the crontab command, they forego a lot of sanity-checking the command provides. – Monty Harder Apr 14 '15 at 15:25
  • @MontyHarder I agree "they are not intended to be edited directly" but what if there is a need of it, like there is a need to make an entry in the crontab via a bash script. you have to use the exact file, I don't think any external interface will help in that case, correct me if I am wrong. – Prabhat Kumar Singh Mar 13 '18 at 08:05
  • @PrabhatKumarSingh You still shouldn't directly edit the file. If you read Celada's command below, you'd have seen an example of how a script could manipulate a crontab file without directly editing it. man crontab explains how this works. – Monty Harder Mar 13 '18 at 20:38
52

heemayl is correct about the location of crontab files on Linux, but it might be different on other operating systems and "theoretically" is could also be in a different location on Linux. Essentially, when a special interface is provided to access the files, you should use it. This will ensure that cron gets to check the files before installing them, makes sure the files have the permissions it needs them to have, etc...

Therefore you should copy a crontab from one user to another using that interface, like this, not by accessing the files directly.

crontab -u <user1> -l | crontab -u <user2>
Community
  • 1
Celada
  • 44,132
  • 3
    There are many good reasons why crontab files should not be directly manipulated by anything other than the OS itself. This is a far better solution. I really think it needs to be incorporated into the official answer. – Monty Harder Apr 13 '15 at 19:07
  • @MontyHarder There isn't really an "official" answer. There is the answer the person asking chose as personally useful to him/her (the one with the checkmark) and the answer the community chose (with the most upvotes). In short, you have 15 rep, you can suggest this is the right answer by upvoting it. Also, if you want to suggest improvements to the other answer, you need to comment on that answer—otherwise, its author won't be notified of your comment. – derobert Apr 13 '15 at 20:34
  • I say "official", you say "accepted". It's the one with the green check mark on it that everyone sees as THE answer, and it's incomplete, because it gives just enough information for people to get in trouble trying to edit crontabs outside of the crontab command itself. I tried to put in an edit on the other answer, incorporating this command, but "peer review" rejected it. – Monty Harder Apr 14 '15 at 15:14
  • @MontyHarder rejecting the edit was absolutely the correct decision. edits must not completely change the meaning of the answer as yours would have. – Celada Apr 14 '15 at 20:39
  • 2
    The corollary of this answer is that one should redirect the output of crontab -l to a file, move the file to the other system, and pipe it to crontab. Or maybe even do it directly (crontab -l | ssh $remote_host crontab). – Blacklight Shining Apr 15 '15 at 01:01
  • @Celada I don't think adding your command would have completely changed the answer at all, because it would have preserved the information previously provided, including the admonition against directly manipulating the file. – Monty Harder Apr 15 '15 at 16:25
  • @MontyHarder Take it up in meta if you feel strongly about it. These comments are not the place. My personal judgement was that it would not have been an appropriate edit and, accordingly, I added my answer as a second answer rather than an edit. It seems like some other community members thought along the same lines because they rejected your edit (I was not one of the reviewers). – Celada Apr 15 '15 at 18:46
  • 7
    "when a special interface is provided to access the files, you should use it." Imagine every application provided a special interface for editing config files instead of just exposing them through the fs, though. That would be quite the annoyance to keep track of. – Witiko Jun 30 '16 at 23:10
  • 3
    As the original asker, I think I should perhasp weigh in on this: The accepted answer was chosen on the basis of my question in its literal sense; the location of the file. My intentions for that file is irrelevant. I don't think editing in the additional info changes the answer, but it might be considered superfluous. – Jarmund Nov 05 '17 at 16:39
  • Please be a bit more open-minded, and accept that the use case you are thinking of probably isn't the only one. In my case, I have a reinstalled system, and I am trying to recover the old crontab of the previous system. The old filesystem was backed up on an external drive, which I have accessible. So I really do need the location of the old crontab, and I really don't need more people telling me to do crontab -l, so while I agree that this could be incorporated into the answer, it certainly isn't the canonically correct answer. – Cookie Sep 21 '23 at 10:24