Answers.Body: <p>To answer non-programmatically for non-coders, the CiviCRM Cron module has been a life saver for us. This will run cron for Civi whenever Drupal's cron runs. Setup is minimal, just needs user, password and sitekey. This allowed me to skirt coding cron.</p>
  
  <p><a href="https://www.drupal.org/project/civicrm_cron" rel="nofollow">https://www.drupal.org/project/civicrm_cron</a> </p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-04-22T17:37:48.830Z
Answers.Text: Intriguing.  This makes a lot of sense.  The author of this module notes in the description "CiviCRM's cron can (and should) be called directly from the command line," though this is a workaround to that.  Do you Allen Hutchinson, or anyone else, know exactly why the module author would make a statement like that?
Answers.UserDisplayName: Daniel Ando Scholnick
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-04-22T19:46:42.280Z
Answers.Text: I'm not sure why. Maybe because it requires a module and is not setup directly on the server? We've been using the module for 18 months, works as advertised.
Answers.UserDisplayName: Allen Hutchison
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-04-22T17:19:05.877Z
Answers.LastActivityDate: 2015-04-22T17:19:05.877Z
Answers.UserDisplayName: Allen Hutchison
Body: <p>Here's my core question:  <strong>Is it ok to allow full write access to Users, Groups, and Others for the directory sites/default/files/civicrm/templates_c/en_US ?</strong></p>
  
  <p>Background:
  I have been running CiviCRM for a while now without getting Cron set up to automatically run (we run it manually, which is terrible).  I'm trying to get this set up finally.</p>
  
  <p>I'd like to run it using Drush, because it does not use a username or password.  This was suggested in the <a href="http://wiki.civicrm.org/confluence/display/CRMDOC/Managing+Scheduled+Jobs" rel="nofollow">wiki on scheduled jobs</a>.</p>
  
  <p>The following drush command works from the command line, but only if I set the permissions of the above mentioned en_US directory as "777", or "users, groups, and others can read, write, and execute."</p>
  
  <blockquote>
    <p>path/to/drush -u 1 -r path/to/drupal -l www.example.org civicrm-api job.execute auth=0 -y</p>
  </blockquote>
  
  <p>If I run this command with the original permissions setting, "755" (drwxr-xr-x) then I get the error message "CiviCRM does not have permission to write temp files in sites/default/files/civicrm/templates_c/en_US/, ExitingDrush command terminated abnormally due to an unrecoverable error."  The owner of the directory is listed as "daemon".</p>
  
  <p>Would it be a terrible thing to allow this directory to be writable by anyone?</p>
  
  <p>CiviCRM 4.5.4
  Drupal 7</p>
  
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2015-05-04T18:52:32.160Z
Comments.Text: Update: I was able to execute the cron command by performing it as the owner of that "en_US" directory, who is the user "daemon".  So, while I haven't received the answer to my original question about permissions on this directory, it's no longer actually critical for me to find an answer.  An expert in the civicrm.stackexchange community may want to chime in on the subject, or just let this question fall away.
Comments.UserDisplayName: Daniel Ando Scholnick
Tags: <drupal><cron-job>
Title: Changing directory permissions to get Cron to work via drush
ThreadText: # Changing directory permissions to get Cron to work via drush
  
  (Asked by: username_0 on 2015-04-22)
  
  Here's my core question: **Is it ok to allow full write access to Users, Groups, and Others for the directory sites/default/files/civicrm/templates\_c/en\_US ?**
  
  Background:
  I have been running CiviCRM for a while now without getting Cron set up to automatically run (we run it manually, which is terrible). I'm trying to get this set up finally.
  
  I'd like to run it using Drush, because it does not use a username or password. This was suggested in the [wiki on scheduled jobs](http://wiki.civicrm.org/confluence/display/CRMDOC/Managing+Scheduled+Jobs).
  
  The following drush command works from the command line, but only if I set the permissions of the above mentioned en\_US directory as "777", or "users, groups, and others can read, write, and execute."
  
  > path/to/drush -u 1 -r path/to/drupal -l www.example.org civicrm-api job.execute auth=0 -y
  
  If I run this command with the original permissions setting, "755" (drwxr-xr-x) then I get the error message "CiviCRM does not have permission to write temp files in sites/default/files/civicrm/templates\_c/en\_US/, ExitingDrush command terminated abnormally due to an unrecoverable error." The owner of the directory is listed as "daemon".
  
  Would it be a terrible thing to allow this directory to be writable by anyone?
  
  CiviCRM 4.5.4
  Drupal 7
  
  **Tags:** drupal, cron-job
  
  > **Comments:**
  > **username_0**: Update: I was able to execute the cron command by performing it as the owner of that "en_US" directory, who is the user "daemon".  So, while I haven't received the answer to my original question about permissions on this directory, it's no longer actually critical for me to find an answer.  An expert in the civicrm.stackexchange community may want to chime in on the subject, or just let this question fall away.  
  
  ---
  
  ## 1 answers
  
  ### Answer by username_1 on 2015-04-22. Score: 2
  
  To answer non-programmatically for non-coders, the CiviCRM Cron module has been a life saver for us. This will run cron for Civi whenever Drupal's cron runs. Setup is minimal, just needs user, password and sitekey. This allowed me to skirt coding cron.
  
  <https://www.drupal.org/project/civicrm_cron>
  
  > **Comments:**
  > **username_0**: Intriguing.  This makes a lot of sense.  The author of this module notes in the description "CiviCRM's cron can (and should) be called directly from the command line," though this is a workaround to that.  Do you Allen Hutchinson, or anyone else, know exactly why the module author would make a statement like that?  
  > **username_1**: I'm not sure why. Maybe because it requires a module and is not setup directly on the server? We've been using the module for 18 months, works as advertised.  
  
  ---
  
  