If I define my cron scheduler via crontab -e, the scheduler works correctly. However, putting the file in /etc/cron.hourly/ doesn't work in my case.

Running run-parts --test /etc/cron.hourly output the script. Also, the script name is my_sql_backup and doesn't have a file extension.

The script is root:root with 777 permission.

The cron.hourly scheduler seems to be working as this is the output of grep CRON /var/log/syslog:

Mar  1 11:17:01 my-instance CRON[12919]: (root) CMD (   cd / && run-parts --report /etc/cron.hourly)

Also, if I manually ran the command, the scheduler ran just like it should:

sudo bash -c "cd / && run-parts --report /etc/cron.hourly"

However, this seems to be not working actually. The script is back up MySQL database to Google Cloud Storage, but the storage isn't updated when I check it via Web Console.

Is there anything I'm missing here? Why does my scheduler script that was put in /etc/cron.hourly/ not work?


Having added the echo test > /tmp/foobar.tmp line to my cron script, I found that the tmp file is there. In fact I found my own tmp file issued by the script.

The content of the script is the following. So maybe the problem occured in running gsutil command?

# define environment variables here
sudo sh -c "mysqldump -u$MYSQL_USER -p$MYSQL_PASS $MYSQL_DBNAME --single-transaction | gzip -9 > $MYSQL_TEMPPATH" >/dev/null 2>&1
gsutil cp $MYSQL_TEMPPATH gs://$GS_BUCKET_NAME/$MYSQL_S3_DESTPATH >/dev/null 2>&1

Again, the script worked fine if I manually ran it, so the environment variables are set to correct values...


I finally found that after getting the log file issued by gsutil command, it has the following content:

AccessDeniedException: 403 Insufficient OAuth2 scope to perform this operation.

I still have to investigate why the access is denied if run in /etc/cron.hourly/... But the problem was on gcloud, not cron... Thank you for the support at the comments.

  • 1
    Having a 777 script that automatically runs as root is a major security vulnerability. You should change that immediately. – Joseph Sible-Reinstate Monica Mar 2 '17 at 3:03
  • @JosephSible But isn't it a problem if no one enters the VM instance via SSH, right? I have little or no knowledge about security, though. – Blaszard Mar 2 '17 at 3:18
  • Whats the script interpreter? – heemayl Mar 2 '17 at 3:20
  • No, it's also a trivial privilege escalation if whatever it is that VM is doing gets compromised. – Joseph Sible-Reinstate Monica Mar 2 '17 at 3:21
  • @heemayl The first line is #! /bin/sh – Blaszard Mar 2 '17 at 3:23

After investigating the log output, I finally found that the log file included the following content which is from the gcloud execution:

AccessDeniedException: 403 Insufficient OAuth2 scope to perform this operation.

So the problem was on gcloud, not cron.

So how to avoid the access denied error on gcloud?

In order to grant VM access the Cloud Storage, take the following steps:

  1. Stop your VM instance

  2. Edit your VM to change the Cloud Storage from Read to Read/Write.

  3. Restart your VM

And now I finally got it working as scheduled...

The source: https://stackoverflow.com/a/41604071/2360798


You have not provided enough information on the script to understand what it's supposed to do nor why it might fail in a cron job - there are a couple common reasons.

However, your question's title and first paragraph (about user and root crontabs) seems clear enough, so let's answer that:

User crontabs and root crontabs have slightly different formats, and are not interchangeable.


1 1 * * * root /bin/foo   // root crontab in /etc/cron*
1 1 * * * /bin/foo        // user crontab in /var/spool (see it using the 'crontab' command

See the difference? A root crontab has an extra field to specify the user. The user need not be root....though in practice it usually is root.

Let's say you want to run a database backup job. Add a root crontab to /etc/cron.d/ that triggers your backup script. Just trigger. One common mistake is to make the crontab more complex than it needs to be. All the logic and error-checking and permissions and logging should be in the script, not the crontab.

  • OP has put the script in /etc/cron.hourly/, and it is being invoked from /etc/crontab using run-parts. What does this answer provide to the context? – heemayl Mar 2 '17 at 3:34
  • @heemayl edited to explain the context better. Thanks for the feedback. – user535733 Mar 2 '17 at 3:51

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.