Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I'm trying to setup a crontab specifically for the user that runs the web process. I have root/sudo access so I wrote an entry for the www-data user using the -e option and here is the listing using the -l option:

/etc$ sudo crontab -u www-data -l
# m h  dom mon dow   command
15,30,45 * * * * /var/www/cron/test.cli.php

The process is not running at the appointed interval however. I'm pretty sure I have the syntax correct so this leads me to a few other possibilities

1) improperly formatted /etc/cron.allow? I actually created this as sudo/root and all I've done is enter a line with "www-data" on it. However, is this the correct format? I'm having a hard time finding information on how /etc/cron.allow should be formatted, its not in the man as far as I can tell (

2) Is /etc the correct location for cron.allow on Debian? I googled and it mentions that it might go elsewhere under SUSE but all indications unless I'm mistaken is that under Debian /etc is the correct location.

3) Permissions for /etc/cron.allow? I (temporarily) set them to 777, could this be too permissive?

4) Does cron need to be restarted after the creation/modification of cron.allow (or cron.deny)?

PS....since first posting this on stackoverflow (where I will now delete it) I have tried restarting cron to no avail: the task still does not run

share|improve this question
1) specifying (#!)/usr/bin/php would be superfluous I already begin my script that way and it runs from the command line and furthermore .... 2) I can run the task from root's crontab .... this seems to suggest that I have not properly setup the ability (via cron.allow?) for www-data to run it's own crontab – George Jempty Oct 21 '09 at 16:23
more or less identical situation (crontab for www-data user) but no solution see… – George Jempty Oct 21 '09 at 16:32
I'm an idiot, it was a permissions problem within the script that was running. Therefore I had actually properly setup the crontab for www-data. Nevertheless I believe this question might be of value and will leave it stand. – George Jempty Oct 21 '09 at 16:41
It's always best to leave the questions on here, so someone in the future may benefit from what's been asked :) Glad I could help point you in the right direction, anyway. – Kyle Smith Oct 21 '09 at 16:45
up vote 1 down vote accepted

As Cornfed said, your .php script would have to start with #!/usr/bin/php for that to work.

1) The cron.allow/deny files only affect a users ability to run the 'crontab' command, not the ability for a user to have a crontab. See man crontab.

2) Yes, also listed in man crontab.

3) Yes, any user could add themselves to that list. That's way too permissive. But in most cases you do not need this file on Debian. From man crontab: "For standard Debian systems, all users may use this command."

4) No, but I have noticed a delay in acceptance of new commands. See /var/log/daemon (I think) for CRON's updating of it's internal files.

share|improve this answer
I appreciate the answer, please see the comments I've added to my question – George Jempty Oct 21 '09 at 16:24 command is accepted in a timely manner when adding to root's crontab – George Jempty Oct 21 '09 at 16:26
Thanks again, I have now actually removed the cron.allow I had previously created and crontab still runs the task for www-data, affirming what you write under #3 regarding probably not needing cron.allow on Debian – George Jempty Oct 21 '09 at 16:52

You might try "15,30,45 * * * * /usr/bin/php /var/www/cron/test.cli.php"

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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