A quick overview: I have a script that will daily backup my source code repository from SVN into a tarball for that day. I have tested the script and it works very well as long as I run it as sudo, because of ownership of the output directory.

So the issue is that I want to run this daily, so I put a link to it in the /etc/cron.daily directory. Here are the contents of the directory.

thom@spenser:/etc/cron.daily$ ls -l
total 60
-rwxr-xr-x 1 root root   189 2011-09-14 02:21 apport
-rwxr-xr-x 1 root root 15535 2011-10-06 11:30 apt
-rwxr-xr-x 1 root root   314 2011-08-08 16:57 aptitude
lrwxrwxrwx 1 root root    24 2012-02-28 11:05 backup -> /usr/local/bin/backup.sh
-rwxr-xr-x 1 root root   502 2011-06-08 11:48 bsdmainutils
-rwxr-xr-x 1 root root   256 2011-10-06 04:04 dpkg
-rwxr-xr-x 1 root root   372 2011-10-04 16:50 logrotate
-rwxr-xr-x 1 root root  1353 2011-07-27 07:17 man-db
-rwxr-xr-x 1 root root   606 2011-08-17 09:16 mlocate
-rwxr-xr-x 1 root root   249 2011-06-24 05:36 passwd
-rwxr-xr-x 1 root root  2417 2011-07-01 17:25 popularity-contest
-rwxr-xr-x 1 root root   383 2011-09-30 15:09 samba
-rwxr-xr-x 1 root root  3594 2011-09-19 20:07 standard

The problem is that it simply never runs. Here is the permissions for that script:

thom@spenser:/etc/cron.daily$ ls -l /usr/local/bin/backup.sh 
-rwxr-xr-x 1 root root 260 2012-02-28 11:03 /usr/local/bin/backup.sh


  • 2
    If possible, please consider closing some of your other open questions by selecting the best answer (if they have one). We need users to maintain their questions so that the site can be an effective tool for the next person with your problems. For more details on best practices consider reading the FAQ on asking questions. Mar 12, 2012 at 10:31

3 Answers 3


Tried this

run-parts --test /etc/cron.daily

Found that my file update.ubuntu did not come up. Also noticed that my file had an extension (has dot in it).

Steps to fix this.

  1. Renamed my update.ubuntu to update-ubuntu
  2. Now again run-parts --test /etc/cron.daily, this time my file came up!
  • 1
    Yeah, this fixed it for me. It doesn't like dots in the filename, renaming my file from myscript.sh to myscript worked for me. Jun 10, 2013 at 9:03
  • 3
    This needs to be higher. I had my script saved as the traditional "backup.sh". Removing the ".sh" part solved it. Thanks a ton!
    – David
    Sep 23, 2013 at 16:32
  • Thanks! The guy/gal who decided to implicitly remove .sh files from the daily cron should be shamed!
    – Sylvain
    Feb 27, 2014 at 9:45
  • Should be publicly flogged! ;-) I wonder how much time people collectively lost because of this decision... I also wonder if there was a good reason for it?
    – xastor
    Apr 6, 2017 at 9:29
  • Lifesaver for me when moving from centos to ubuntu. Sep 5 at 14:38

Could be one of several things:

Roots path:

Depending on the commands being run, you may need to expand the root users PATH variable by putting the following line at the top of their crontab file:


src: https://help.ubuntu.com/community/CronHowto

Or just use full paths to each command in your script: /bin/ls instead of ls for example. (which ls at command line for paths).

There is a strange bug about dots in the filename reported here. Might extend to the file you are linking to, although this seems unlikely.

Are you saving the output from the backup file? Put something like this on the first line, to help determine if it is not running at all or running but failing at some point.

/bin/echo "Attempting to run backup" >> /path-to-home/backup.log

Alternatively try adding the script to the crontab file directly:

sudo -i
crontab -e
[add the next line to the file, then save and exit]
33 15 * * * /usr/local/bin/backup.sh

will run at 15:30 every day if the machine is on. use * * * * * while testing to run once a minute until you get it working.

  • 1
    Using absolute paths in scripts is discouraged. If you don't know what PATH is, set it yourself in the script. See Reasons why crontab does not work
    – geirha
    Mar 12, 2012 at 12:37
  • Useful link, thanks. The given reason not to use full paths is portability. Fair enough. Another reasonable solution is to define the commands you are using at the start of the script, along with other configurations: LS=/bin/ls; SRC_DIR=/home/joe/src. Then use $LS $SRC_DIR. Keeps everything defined at the top and in one place.
    – Sean
    Mar 12, 2012 at 12:50
  • I find that to reduce readability, and you have to go over every COMMAND=/path/to/command for every new system it should run on. On one system, all the commands you need could be in /usr/bin, on another some are in /bin, others in /usr/bin. Just having both /usr/bin and /bin in PATH makes that a non-issue. On a side note, variable names should be lowercase, else you risk overriding special shell variables or environment variables.
    – geirha
    Mar 12, 2012 at 14:54
  • re: upper case variable names. I have always done that without much thought, due to the first scripts I saw doing it. But you are right, there is no upside and a chance of downside. Thanks for pointing this out, breaking this habit now.
    – Sean
    Mar 14, 2012 at 10:30

Grep your syslog for messages like;

crond: (*system*) BAD FILE MODE

the files need to be restricted to (is sufficient) at 644):

chmod 0644 /etc/cron.d/my_crontab

You must log in to answer this question.

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