14

I see that my user is a member of the apache group. I added and confirmed via the following

$ sudo usermod -a -G apache `whoami`  # add my user to apache group
$ sudo chmod -R g+w .                 # permit group members to write 
$ groups `whoami`                     # confirm I'm in the apache group

However, when I attempt to run a drush update core or even drush cron

$ drush cc all

unlink(sites/default/files/css/css_71ba7c25a8d3c47c68a8e05608ae525c.css):[warning]
Permission denied file.inc:482

enter image description here

And the CSS cache in this situation looks like

$ ll
total 1536
drwxrwxr-x.  2 apache apache  12288 Nov 26 10:12 .
drwxrwxr-x. 11 apache apache   4096 Nov 24 20:35 ..
-rw-rw-r--   1 apache apache 162269 Nov 26 10:06 css_00d5f4d7c5c92cd4f.css
-rw-rw-r--   1 apache apache 158090 Nov 26 10:02 css_0605989692a2119d305.css
-rw-rw-r--   1 apache apache 162269 Nov 26 10:02 css_0779dcac71ee9aa8e02d9e.css

enter image description here

I would assume that my user account, which has sudo access, should be a group member of apache (or www-data) and that the file tree should permit group write access. Any help or points in the right direction would be much appreciated.

2
  • 2
    run newgrp apache without sudo and try again Commented Nov 26, 2012 at 16:45
  • 2
    Did you log out and then back in again?
    – mpdonadio
    Commented Nov 26, 2012 at 16:52

4 Answers 4

15

Arguably, a much more straightforward approach is to not muck with your user's group assignments at all and instead run drush as the web server user (ie: apache, www-data).

Use sudo:

sudo -u apache drush

or on debian/ubuntu:

sudo -u www-data drush

Create a command alias:

Then, to ensure that you always run drush like that, add an alias:

echo "alias drush='sudo -u apache drush'" >> ~/.bash_aliases 

or on debian/ubuntu:

echo "alias drush='sudo -u www-data drush'" >> ~/.bash_aliases 

Now when running any drush command, you'll be prompted for your password by sudo, and the command will run as the web server user. No more permissions problem reading and writing files.

3
  • 1
    When I run "sudo -u www-data drush" it complains that the drush-backups directory is not writable.
    – Magmatic
    Commented Apr 26, 2018 at 15:22
  • 1
    @Magmatic just change permissions to that folder, make it writeable for www-data, check who is the owner. Commented Apr 28, 2018 at 12:39
  • I have a related issue here where I'm trying to run drush commands against the production server via remote site aliases. Do you have any insight as to how to accomplish this? drupal.stackexchange.com/questions/312977/…
    – blue928
    Commented Sep 15, 2022 at 22:40
4

Though the other answer is informative, I now use the proper user permission as described in

Securing file permissions and ownership

Which opens with

The server file system should be configured so that the web server (e.g. Apache) does not have permission to edit or write the files which it then executes. That is, all of your files should be 'read only' for the Apache process, and owned with write permissions by a separate user.

4
  • 3
    The article that you link to does not mention Drush. Could you, please, clarify which user you are using to run Drush commands and how is that user set up.
    – JW.
    Commented Sep 24, 2015 at 16:14
  • 2
    Interesting! I think you should also mention the 2 pargs that follow the one you already quoted ... Commented Jul 16, 2016 at 8:58
  • 2
    In Drupal files folder needs to be writable by the webserver, and in development you will probably need that for features folder too. Commented Apr 28, 2018 at 12:45
  • This article also says: "...For the "files" directory in the sites/default directory and any other site directories in a multi-site installation, the permissions are slightly different because the www-data user must have write permission to the directory:..." [root@localhost]cd /path_to_drupal_installation/sites [root@localhost]find . -type d -name files -exec chmod ug=rwx,o= '{}' \; Commented Feb 20 at 8:48
1

When I ran drush as www-data drush was no longer available as my $PATH had changed.

As a workaround you can enter the whole path to drush.

E.g.

sudo -u www-data /home/vagrant/.composer/vendor/bin/drush status

To get the path of your drush you can run:

which drush

Which means you can also just run:

sudo -u www-data `which drush` status

which removes the need to hard code the path in the command.

0

Inside files folder

chown -R youruser:www-data .
find . -type d -exec chmod ug=rwx,o= '{}' \;
find . -type f -exec chmod ug=rw,o= '{}' \;

See: https://www.drupal.org/node/244924#linux-servers

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.