Two users are trying to access the temp files (where, for instance, the compiled templates are stored): www-data (when it's accessed from the website) and the sysadmin that run drush commands

By default, all these temporary files can only modified by the user that created it, so sometimes it's the sysadmin, sometimes it's the webserver user

Is there a way so all the temp files can be created/modified/deleted by only the admin user(s) and www-data?

One possible fix is a patch on drush, so it uses a separate templates_c folder than the one used by www-data. Could you test if it works in your environment/workflow?



4 Answers 4


There's no single perfect solution to this, but there are several adequate solutions. To highlight some trade-offs among the approaches raised so far:

  • For each security principal, use separate data-directories (like bgm's answer).
    • Pro: Portable -- works in many different environments. Doesn't require any special tools or root permissions.
    • Con: Only works when data can be split apart by user. For example, it could potentially work for logs/caches (because they don't really need to be shared) but is more problematic for uploads/attachments (because both users should have read/write on the same objects).
  • Create a cronjob or daemon to adjust permissions (like Chris's answer)
    • Pro: Portable -- you can design the daemon or cronjob to build on the traditional POSIX UGO/RWX triplets. Works with all data (logs/caches/attachments).
    • Con: Requires installing/running a new root-permissioned service. Watch out for symlinks/hardlinks.
  • Use the operating system's ACL features (like amp's linuxAcl and osxAcl policies)
    • Pro: Works with all data (logs/caches/attachments). Doesn't require daemon or regularly running as root.
    • Con: Not standardized -- technical steps depend on the environment (OS/distro/filesystem). Sometimes applications try to be clever and override the permissions -- which breaks ACLs for specific files/use-cases.
    • (Note: amp tries to abstract this, but as with any abstraction, it's probably not worth the overhead unless you buy into the general vision.)
  • Do you see any case where drush could need to create/modify a file that needs to be shared with the www-data user?
    – Xavier
    Jun 2, 2015 at 7:27
  • (1) Destroying+recreating demo sites. (For *.demo.civicrm.org, we get bitten by CRM-12169 and need to use work-arounds to let the console user delete attachments created by the web user.) (2) Importing or exporting data via the Attachment API. (3) Flushing templates_c as part of upgrading/migration/development. (Strictly speaking, one could work-around #3 by putting a nonce in the path for templates_c and changing the nonce whenever you flush the cache; then it doesn't matter if you delete the stale cache files. But that's not an obvious change.)
    – Tim Otten
    Jun 2, 2015 at 10:24
  • duh, having different paths on my patch means NOT deleting the templates_c if drush CC. Not so good at all. @bmg workaround idea not good enough imo
    – Xavier
    Jun 2, 2015 at 12:10

Setting directories group-setuid might get you part of the way (with chmod g+ws templates_c), but maybe we should consider something like this in the CiviCRM drush module?:

$config = CRM_Core_Config::singleton( );
$config->configAndLogDir = $config->configAndLogDir . 'drush/';
$config->templateCompileDir = $config->templateCompileDir . 'drush/';

i.e. create templates in a sub-directory of templates_c/drush/, this way the web server (www-data) will not have trouble writing in the templates/logs later on.

This is what Aegir did for a long time, but due to a regression it has not been working for a while and since then I run into that issue as well.

  • I like this (could we just set the FS cache to /dev/null in Drush?), it seems like it would work around issues like CRM-15632: Don't exit if templates_c unwriteable. Caching to an unpermissioned environment (eg memcache) might also eliminate the same. Or perhaps include the current UID in the cache path or hash? Jun 1, 2015 at 23:48
  • Hi, tried, it chokes on the templates_c in the singleton(). Workaround I found, please test and comment: github.com/civicrm/civicrm-drupal/pull/286
    – Xavier
    Jun 2, 2015 at 8:35
  • Furthermore, as Tim pointed out, this will break things such as "drush cvapi System.flush", since CiviCRM will not flush the correct template_c directory.
    – bgm
    Jun 3, 2015 at 14:21

Tim describes a solution based on linux ACL:


But it requires amp, that I (might be wrongly) see a dev only tool. Does someone use something like that in production?

  • 1
    We make use of POSIX ACL with XFS at the Apache website directory /srv/www. I am not quite totally satisfied with the operational results... there still are times I must sudo as the ACL did not override the file system operation. Yes, to clean up temp files CiviCRM creates, even though due to the ACL new objects get created as group www-data, and my ID is a member of that group, for now I must sudo to be able to purge. Jun 2, 2015 at 2:00
  • FWIW, you don't need to use amp to use ACLs. The first few sections of perm.md are general/architectural. The amp datadir commands are thin wrappers for equivalent commands using setfacl (Linux) or chmod +a (OSX). If you want to see exactly what amp datadir does in each environment, read github.com/totten/amp/blob/07aceace79/app/defaults/…
    – Tim Otten
    Jun 2, 2015 at 5:49

Our solution to mixed access to CiviCRM's cache files (and other situations where permissions issues arose) has been a daemon which monitors filesystem entries and "corrects" permissions immediately on file creation/modification.

There are still some issues with this approach (eg issue linked in comment on bgm's answer), but it seems to work out better than just relying on setgid (which I'd hope could be a complete solution).

I'm still a bit unsure of our taking this route - I'd prefer for UNIX permissions to work for people! They are simple and well-tested after all ... - but at least it's no longer a support headache :)

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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