Answers.Body: <p><a href="https://docs.civicrm.org/dev/en/latest/tools/civibuild/" rel="nofollow noreferrer">civibuild</a> shows a few ways to tackle this problem.</p>
  
  <p><a href="https://help.ubuntu.com/community/FilePermissionsACLs" rel="nofollow noreferrer">File Permission ACL's</a> work well if they are available on your system.</p>
  
  <p>Edit: You will need to set the ACLs to cover future files created in the directory as well as existing ones. For this, use the <strong>-d</strong> flag as shown here <a href="https://serverfault.com/a/445096">https://serverfault.com/a/445096</a>.</p>
  
  <p>Further edit: Set the ACLs on the <strong>civicrm</strong> directory above the <strong>templates_c</strong> directory. Sometimes the whole <strong>templates_c</strong> directory gets deleted and rebuilt.</p>
  
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2018-08-12T17:37:02.900Z
Answers.Text: Thanks. I went for the FACL method. I've edited the answer to include another step - you have to set the ACLs to automatically set themselves on files as they are created.
Answers.UserDisplayName: naomi
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2018-07-04T10:36:50.257Z
Answers.LastActivityDate: 2018-08-20T11:40:45.320Z
Answers.LastEditDate: 2018-08-20T11:40:45.320Z
Answers.UserDisplayName: Aidan
Answers.Body: <p>Our rule is run everything drush that touches files owned by apache as apache:</p>
  
  <pre><code>sudo -u apache drush cc all
  </code></pre>
  
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2018-08-03T13:59:05.433Z
Answers.LastActivityDate: 2018-08-03T13:59:05.433Z
Answers.UserDisplayName: KarinG - Semper IT
Body: <p>This is related to, but not a duplicate of, <a href="https://civicrm.stackexchange.com/questions/16618/civicrm-rebuilding-templates-c-with-permissions">CiviCRM rebuilding templates_c with permissions</a>.</p>
  
  <p>I am using civicrm 5.1.2 / Drupal 7 /  Apache / Linux.</p>
  
  <p>It is best practice not to let <code>www-data</code> own files in the Drupal tree. By the principle of least privilege, the web server should not be allowed to write to directories that it does not need to write to. And obviously someone needs to be able to write to them so that you can log on and upgrade and so on.</p>
  
  <p>So I set up the permissions as suggested <a href="https://www.drupal.org/node/244924#configuration-examples" rel="noreferrer">here</a> . User <code>jane</code> has ownership of all the files and directories apart from the <code>files</code> directory, which is owned by <code>www-data</code>. </p>
  
  <p>This does not work with CiviCRM and drush. </p>
  
  <p>When you do a <code>drush cc</code> or <code>drush cvupdb</code> in the command line, as <code>jane</code>, the <code>templates_c</code> and <code>ConfigAndLog</code> directories get files added to them with owner <code>jane</code> and group <code>www-data</code> (I have set the setgid bit in order to ensure that the group remains <code>www-data</code>) and they get created with group write permissions. That is all well and good - the web server has write permissions via the group, and then is able to update the files when it needs to.</p>
  
  <p>But when the web server creates the files itself, it creates them with <code>www-data</code> as both the group and the user. This is of course all it can do. However, it does not set group write permissions. That means that the next time <code>jane</code> logs on to do something from the command line that writes to those directories, she can't.</p>
  
  <p>What do you suggest?</p>
  
Tags: <drupal><filesystem>
Title: Templates_c permissions differ when rebuilt on command line or by apache
ThreadText: # Templates_c permissions differ when rebuilt on command line or by apache
  
  (Asked by: username_0 on 2018-07-04)
  
  This is related to, but not a duplicate of, [CiviCRM rebuilding templates\_c with permissions](https://civicrm.stackexchange.com/questions/16618/civicrm-rebuilding-templates-c-with-permissions).
  
  I am using civicrm 5.1.2 / Drupal 7 / Apache / Linux.
  
  It is best practice not to let `www-data` own files in the Drupal tree. By the principle of least privilege, the web server should not be allowed to write to directories that it does not need to write to. And obviously someone needs to be able to write to them so that you can log on and upgrade and so on.
  
  So I set up the permissions as suggested [here](https://www.drupal.org/node/244924#configuration-examples) . User `jane` has ownership of all the files and directories apart from the `files` directory, which is owned by `www-data`.
  
  This does not work with CiviCRM and drush.
  
  When you do a `drush cc` or `drush cvupdb` in the command line, as `jane`, the `templates_c` and `ConfigAndLog` directories get files added to them with owner `jane` and group `www-data` (I have set the setgid bit in order to ensure that the group remains `www-data`) and they get created with group write permissions. That is all well and good - the web server has write permissions via the group, and then is able to update the files when it needs to.
  
  But when the web server creates the files itself, it creates them with `www-data` as both the group and the user. This is of course all it can do. However, it does not set group write permissions. That means that the next time `jane` logs on to do something from the command line that writes to those directories, she can't.
  
  What do you suggest?
  
  **Tags:** drupal, filesystem
  
  
  ---
  
  ## 2 answers
  
  ### Answer by username_1 on 2018-07-04. Score: 0 | Accepted answer
  
  [civibuild](https://docs.civicrm.org/dev/en/latest/tools/civibuild/) shows a few ways to tackle this problem.
  
  [File Permission ACL's](https://help.ubuntu.com/community/FilePermissionsACLs) work well if they are available on your system.
  
  Edit: You will need to set the ACLs to cover future files created in the directory as well as existing ones. For this, use the **-d** flag as shown here <https://serverfault.com/a/445096>.
  
  Further edit: Set the ACLs on the **civicrm** directory above the **templates\_c** directory. Sometimes the whole **templates\_c** directory gets deleted and rebuilt.
  
  > **Comments:**
  > **username_0**: Thanks. I went for the FACL method. I've edited the answer to include another step - you have to set the ACLs to automatically set themselves on files as they are created.  
  
  ---
  
  ### Answer by username_2 on 2018-08-03. Score: 0
  
  Our rule is run everything drush that touches files owned by apache as apache:
  
  ```
  sudo -u apache drush cc all
  
  ```
  
  
  ---
  
  