Aggregation not working css and js cache directories not being created

Created on 15 August 2023, 7 months ago
Updated 24 February 2024, 7 days ago


After upgrading to 10.1.2, aggregation no longer works. It appears that the css and js folders are not being created.

We are using Apache 2.4.57 and PHP 8.1.22

We did update our .htaccess file.

Turning off aggregation, and everything works/loads correctly.

Steps to reproduce

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

๐Ÿ’ฌ Support request

Postponed: needs info


11.0 ๐Ÿ”ฅ

Asset libraryย  โ†’

Last updated 7 days ago

No maintainer
Created by

๐Ÿ‡บ๐Ÿ‡ธUnited States edmund.dunn Olympia, WA

Live updates comments and jobs are added and updated live.
Sign in to follow issues

Comments & Activities

Not all content is available!

It's likely this issue predates : some issue and comment data are missing.

  • Issue created by @edmund.dunn
  • Status changed to Postponed: needs info 7 months ago
  • ๐Ÿ‡บ๐Ÿ‡ธUnited States cilefen

    In what way did you update the .htaccess file?

    Is this a known outcome of ๐Ÿ“Œ Remove the aggregate stale file threshold and state entry Fixed ? You related it. Oh, I see you commented there, so I think you are opening this issue as a follow-up. Have you tried reverting the changes in ๐Ÿ“Œ Remove the aggregate stale file threshold and state entry Fixed to be sure? The changes are small.

  • Status changed to Active 7 months ago
  • ๐Ÿ‡บ๐Ÿ‡ธUnited States cilefen

    I didn't mean to postpone this after further reading.

  • ๐Ÿ‡ฉ๐Ÿ‡ชGermany zcht

    I have exactly the same problem unfortunately, aggregation turned off, everything works, turned on.... 404 error and the files are not generated. I use Drupal 10.1.2, PHP 8.1.22, nginx 1.24. The new nginx statement from the CR ( โ†’ ) are implemented. Also the tips from the issues from comment 2 have already been worked through, nothing helps unfortunately.

  • ๐Ÿ‡ฉ๐Ÿ‡ฐDenmark ressa Copenhagen

    I am also seeing this error, which could be related?

    $ drush cache:rebuild
    PHP Warning:  unlink(/var/www/html/ Permission denied in /var/www/html/ on line 124
     [error]  Failed to unlink file 'assets://css/css_Dd8YCdHfaQEgt3dWdSVw94rP7EmTUdfBCOWw7Z_fzr8.css'.

    More possibly related issues? and โœจ Generated scripts owner Fixed .

  • ๐Ÿ‡บ๐Ÿ‡ธUnited States cilefen

    First, to make sure everyone is reporting the same problem: in precisely which Drupal version did this behavior begin?

  • ๐Ÿ‡ฉ๐Ÿ‡ชGermany zcht

    In my case with 10.1.1, at the moment running on the productive environment Drupal 9.5.10, in the meantime, the instance was prepared for Drupal 10 and updated to the then most current Drupal 10.0.x. Under this version everything still ran problem-free, after the update to 10.1.1 and now 10.1.2, came the problem, which could not be solved so far. All under the same PHP and nginx version.

  • ๐Ÿ‡ฉ๐Ÿ‡ฐDenmark ressa Copenhagen

    I am seeing this in 10.1.2, I believe updating from 10.1.0.

    I have previously chowned all folders to webuser:www-data, but it looks like Drupal reverts js and css to www-data:www-data. Did this a while ago:

    $ cd /var/www/html/
    $ chown -R webuser:www-data .

    Owner has been changed at some point:

    $ ls /var/www/html/
    total 24K
    drwxrwx--- 3 webuser      www-data 4,0K Jun 18 19:31 config_gocPFbHI7[...]
    drwxrwxr-x 2 www-data www-data 4,0K Aug 11 12:01 css
    drwxrwxr-x 2 www-data www-data 4,0K Aug 11 12:02 js
    drwxrwx--- 3 webuser      www-data 4,0K Aug 10 14:33 php
    drwxrwx--- 2 webuser      www-data 4,0K Jun 18 19:31 styles
  • ๐Ÿ‡บ๐Ÿ‡ธUnited States cilefen

    Some people are reporting directories not being created and others, a Drush permissions problem. Are these the same?

    Each of 10.1.0, 10.1.1, and 10.1.2 made changes to the asset library system. There were a handful of bug reports following 10.1.0. I am trying to understand if this issue (or issues?) is distinct from the ones previously-reported.

  • ๐Ÿ‡บ๐Ÿ‡ธUnited States edmund.dunn Olympia, WA

    We are in the process of upgrading to D10 from D9.5. We didn't notice the issue until we got it up on our test instance for testing. On our local and dev environments, we have aggregation turned off so we hadn't noticed any issues.

    Turning aggregating off does fix the issue.

  • ๐Ÿ‡ฉ๐Ÿ‡ฐDenmark ressa Copenhagen

    I can confirm that turning off aggregation makes the error message go away.

    In my situation, everything works, and the js and css folders are created when I turn on aggregation and the aggregated CSS files are present. The only problem is that I get an assets error after drush cache:rebuild.

    It looks like to me, that the problem is that Drupal doesn't use the owner combination of the parent files folder. So, for example if the owner of the files folder is webuser:www-data, the created js and css folders should maintain this combination, and not set it to www-data:www-data:

    $ ls /var/www/html/
    -rw-r----- 1 webuser www-data 8,9K Aug 10 12:35
    -rw-r----- 1 webuser www-data  35K Aug 10 12:35 default.settings.php
    drwxrwx--- 8 webuser www-data 4,0K Aug 16 20:05 files
    $ ls /var/www/html/
    drwxrwx--- 3 webuser  www-data 4,0K Jun 18 19:31 config_gocPFbHI7shz[...]
    drwxrwxr-x 2 www-data www-data 4,0K Aug 16 20:05 css
    drwxrwxr-x 2 www-data www-data 4,0K Aug 16 20:05 js
  • ๐Ÿ‡ฌ๐Ÿ‡งUnited Kingdom longwave UK

    Drupal doesn't do anything with regard to users and groups; it leaves this up to the operating system. You have both webuser and www-data - if you are running drush as one user and your webserver as another, it is likely you will run into permission issues. You should try running drush as the same user as your webserver via sudo or a similar mechanism.

  • ๐Ÿ‡ฉ๐Ÿ‡ฐDenmark ressa Copenhagen

    Thanks @longawave. I am only guessing at what could be the reason for the assets-error, and it might not be the cause. Having those owner settings could be perfectly fine.

    I use the set up from โ†’ and do run everyday tasks as webuser. I haven't had any problems so far, until Drupal 10.1.2.

  • Status changed to Postponed: needs info 7 months ago
  • ๐Ÿ‡ฌ๐Ÿ‡งUnited Kingdom catch

    This needs steps to reproduce. zcht is talking about ngnix, edmund.dunn is talking about apache. These are likely to be completely separate issues so should be split, however without details of the problem and setups, it's impossible to help.

    @ressa it sounds like you had an existing problem with file permissions ownership that the assets changes exposed, I don't think it's something that core can help with as @cilefen says.

  • ๐Ÿ‡ฎ๐Ÿ‡ณIndia JaydipJD surat

    I am facing the same issue today. I just took fresh D10.1.2 and did local setup. I am getting the same error when i hit drush cr. permission for files directory got changed automatically.

  • ๐Ÿ‡ฎ๐Ÿ‡ณIndia JaydipJD surat

    Didn't get any error when i disabled aggregation for js and css.

  • Status changed to Active 6 months ago
  • ๐Ÿ‡บ๐Ÿ‡ฆUkraine voleger Ukraine, Rivne

    I'm experiencing the same issue. I have wodby/docker4drupal docker compose stack, drupal:10.1.2, php:8.1.16, nginx:1.17.10.

    So I enabled the css aggregation. Generated URLs for the css assets return 404 status. I'm going to check web/sites/default/files/css folder existence.

    The directory does not exist.

    1st test case:
    - mkdir web/sites/default/files/css
    - drush cr
    Expectations: css folder stays in place.
    actual result: css folder removed on cache rebuild

    2 test case:
    - mkdir web/sites/default/files/css
    - click the 'Clear all cache' button on the Performance admin page.
    expectations: css folder stays in place.
    actual result: css folder removed on cache rebuild

  • ๐Ÿ‡ฌ๐Ÿ‡งUnited Kingdom catch

    Expectations: css folder stays in place.
    actual result: css folder removed on cache rebuild

    This is by design - the cache clear just removes the entire folder. However the first asset created should recreate the folder immediately.

    That the folder exists in the first place to be recreated suggests that aggregates were also in there? If they're not being created, you should check the Drupal logs for what the error is - if it's file permissions, you need to ensure that files/directories created by the webserver vs. drush have the same permissions and ownership.

  • ๐Ÿ‡บ๐Ÿ‡ฆUkraine voleger Ukraine, Rivne

    Figured out the cause of the issue. In my case it was outdated nginx preset configuration.

  • Status changed to Postponed: needs info 6 months ago
  • ๐Ÿ‡ฌ๐Ÿ‡งUnited Kingdom catch

    @voleger could you open an issue for that? We have had issues with self-http requests before, so not sure whether it's possible to detect the misconfiguration, but maybe worth exporing.

    Moving back to needs more info again for the other reports.

  • ๐Ÿ‡น๐Ÿ‡ทTurkey Orkut Murat Yฤฑlmaz

    Hello all,

    I'm linking a related issue ๐Ÿ› FileSystem::deleteRecursive() shouldn't log a message when it tries to delete a non-existent directory Fixed with close experience of mine, which was solved by changing nginx configuration.

    Also, updating the version of wodby's docker4drupal solves the issue, on local development environment as well.


  • ๐Ÿ‡บ๐Ÿ‡ฆUkraine voleger Ukraine, Rivne

    In MR of โœจ Allow to validate Apache/Nginx configuration requirement for aggregation folder before enabling aggregation. Needs review , added a validation button on the Performance admin page.

  • ๐Ÿ‡ฎ๐Ÿ‡ณIndia kunalbaghel

    i am facing the same issue getting the error of Failed to unlink file 'assets://css/css_vdedfbedkk433HDLWSBDBKsd789.css' and the permission set to www-data

  • ๐Ÿ‡น๐Ÿ‡ทTurkey Orkut Murat Yฤฑlmaz

    @kunalbaghel, have you seen this issue ๐Ÿ› Directory permissions (and ownership) change after cache:rebuild Active ?

  • ๐Ÿ‡ฎ๐Ÿ‡ณIndia kunalbaghel

    Yes I had seen.

  • ๐Ÿ‡น๐Ÿ‡ทTurkey Orkut Murat Yฤฑlmaz

    @kunalbaghel, I think that the problem is not about the which web server we use.

  • ๐Ÿ‡ฎ๐Ÿ‡ณIndia mufaddal009

    Un-commenting and changing this in settings.php solves my problem but why does this occur in first place?

    $settings['file_chmod_directory'] = 0777;
    $settings['file_chmod_file'] = 0664;
  • ๐Ÿ‡ฎ๐Ÿ‡ณIndia kunalbaghel

    Don't Know How, by un-commenting and adding the path to file_private_path OR file_public_path in settings.php is worked for me

    $settings['file_private_path'] = 'sites/default/files';
    $settings['file_public_path'] = 'sites/default/files/public';

  • ๐Ÿ‡น๐Ÿ‡ทTurkey Orkut Murat Yฤฑlmaz

    @mufaddal, what was your problem?

    @kunalbaghel, it is not a good practice to set private file directory as sites/default/files for Drupal.

  • ๐Ÿ‡ฎ๐Ÿ‡ณIndia kunalbaghel

    Thank you @OrkutMuratYฤฑlmaz ,

    Yes, you're correct. I was just trying to fix the issue and got curious about how it worked.

  • ๐Ÿ‡ฎ๐Ÿ‡ณIndia mufaddal009

    @OrkutMuratYฤฑlmaz, when i rebuild the cash using drush it changes the permission of css and js folder inside the default/sites/files folder to 775 i need the permission to be 777

  • ๐Ÿ‡ฌ๐Ÿ‡งUnited Kingdom catch

    @mufaddal009 you either need to configure drush/cli php so that the chmod is the same as what your webserver does, or run drush as the webserver user (www-data or similar), or do what you did in #27.

  • ๐Ÿ‡ฉ๐Ÿ‡ฐDenmark ressa Copenhagen

    Could it be that a lingering JS or CSS file triggered this message? I can't reproduce the issue now, and the only thing I can think of that's different, is that I emptied the two folders /sites/default/files/css and /sites/default/files/js and reapplied permissions according to the recommendations in Securing file permissions and ownership โ†’ . Now, if I clear cache I no longer get an error message:

    $ drush cache:rebuild
     [success] Cache rebuild complete.

    @kunalbaghel and @mufaddal009: Before adding those configs in settings.php it's probably best to make sure the server is configured according to Securing file permissions and ownership โ†’ .

  • ๐Ÿ‡ฎ๐Ÿ‡ณIndia kunalbaghel

    Thank you @ressa,

    I'll verify the server permissions again.

  • ๐Ÿ‡บ๐Ÿ‡ธUnited States gelierb

    I've had this same issue and spent a lot of time thinking it was something to do with permissions, etc. Finally realized it was only happening on websites with a Bootstrap sub-theme (switch to Olivero, etc. fixed the problem). Did a require bootstrap with composer and everything seemed OK, css and js directories were built, etc.

  • I don't know if this will help anyone but it was the missing piece for my system: ๐Ÿ› 10.1.x breaks Nginx + PHP-FPM with too many redirects even when nginx config is changed Closed: works as designed

  • ๐Ÿ‡ณ๐Ÿ‡ฟNew Zealand heathergaye

    Hi, just an FYI in case it's relevant to anyone: I also had this issue on a Drupal 10.1.4 upgrade, using Apache.

    My problem was caused by the fast404 contrib module. There is already an issue opened and resolved here: ๐Ÿ› Fast404 prevents css/js assets from generating when aggregation is enabled on Drupal 10.1 Fixed

  • ๐Ÿ‡ฌ๐Ÿ‡งUnited Kingdom catch
  • For what it's worth; I upgraded from d9 to d10 on Lando with the drupal9 recipe. CSS/JS Aggregation was borked until I thought to rebuild using the drupal10 recipe.

    name: funky-site-name
    recipe: drupal10
      php: 8.1
      webroot: web
      via: nginx
  • ๐Ÿ‡น๐Ÿ‡ทTurkey Orkut Murat Yฤฑlmaz

    Hello everyone,

    Please check this issue ๐Ÿ› Warning: file_put_contents(public://ipless/ipless-ipless.watching--ipless.watching.css Closed: works as designed . It is about ownership and permissions of drush.

    Thanks everyone for solving this one.


  • ๐Ÿ‡บ๐Ÿ‡ธUnited States darrell_ulm

    Could this actually have been a change to Drush version 10 or 11 ? Running Drupal 10.5, or I don't think this was always the case, possibly Drupal 10.1.1, the error seems to be more with Drush than Drupal.

    permission groups for Ubuntu used for file directory only are
    as per โ†’ like:

    drwxrwx--- 7 www-data greg-group 4096 2008-01-18 11:02 files/
    drwxr-x--- 32 greg-user www-data 4096 2008-01-18 11:48 modules/
    -rw-r----- 1 greg-user www-data 873 2007-11-13 15:35 index.php

    When new JS and CSS files are created rather than keeping these permissions

    drwxrwx--- 7 www-data greg-group 4096 2008-01-18 11:02 files/

    the permissions are re-written to

    drwxrwx--- 7 www-data www-data 4096 2008-01-18 11:02 files/

    and this could be because the js and css directories appear to be deleted completely before they are repopulated. this can be seen after doing a directory permissions sweep and then running
    drush cr

    I notice that when running Drush from webroot as as the www-data user, drush cr works fine as would expect, but still changing the js and css directory permissions, likely because Drupal now deletes the js and css directories, and they are recreated as:
    for the user groups.

    sudo -g www-data ./vendor/bin/drush cr

    Drupal cache clear works fine.

    However, drush as the non www-data user does not work once the js and css directories have been populated with the
    user + group.

    $ drush cr
    [warning] unlink(.../sites/default/files/css/css_bdWeT0sNlgIx6Vhnvg713u12RoNiC0AwD6fXvvLan-8.css.gz): Permission denied FileSystem.php:124

    In FileSystem.php line 326:
    Failed to unlink file 'assets://css/css_bdWeT0sNlgIx6Vhnvg713u12RoNiC0AwD6fXvvLan-8.css.gz'.

    Hope this gives some insight, as it definitely works back in Drupal 9.

  • ๐Ÿ‡ฉ๐Ÿ‡ชGermany yan

    My problem was like the one described in the original issue - css and js directories were not created. This happened after an upgrade from Drupal 8 to 10.2 on a Debian server using Apache. When I saved the settings on /admin/config/development/performance, I got this error message:

    'stale_file_threshold' is not a supported key.

    Similarly, on /admin/config/media/file-system I got:

    'filename_transliteration' is not a supported key.

    It seems, these invalid keys were still stored in my configuration. I searched for the strings in my code base and found a config-sync file holding them:

    $ grep -rnw . -e 'stale_file_threshold'
    /config-sync/system.performance.yml:18:stale_file_threshold: 2592000
    $ grep -rnw . -e 'filename_transliteration'
    ./config-sync/system.file.yml:9:filename_transliteration: true

    Removing them like this solved my problem:

    $ drush config:delete system.performance stale_file_threshold
    $ drush config:delete system.file filename_transliteration

    I thought this might help others finding this issue.

  • ๐Ÿ‡ฉ๐Ÿ‡ชGermany zcht

    @yan Thanks, had the exact same problem after updating to Drupal 10.2... your solution worked great.

  • ๐Ÿ‡บ๐Ÿ‡ธUnited States caspervoogt

    Thanks @heathergaye, fast404 caused it in my case, and updating from v2 to v3 solved it.

  • ๐Ÿ‡น๐Ÿ‡ทTurkey Orkut Murat Yฤฑlmaz

    @yan Thanks, I've used your solution here ๐Ÿ› 'ipless' is not a supported key. Active too.

  • ๐Ÿ‡ต๐Ÿ‡ฑPoland besek

    Thanks @yan solution #43 really helped!

  • ๐Ÿ‡น๐Ÿ‡ทTurkey Orkut Murat Yฤฑlmaz

    Please check this comment ๐Ÿ› 'ipless' is not a supported key. Active .

  • ๐Ÿ‡บ๐Ÿ‡ธUnited States darrell_ulm

    Hmmm, #43 not working here for Drupal 10.1.n, will keep looking, but thanks for the update, it make work for some.

  • ๐Ÿ‡ฎ๐Ÿ‡ณIndia vishal.kadam Mumbai

    I have resolved the issue by simply following the below steps:

    1. Re-save the "/admin/config/media/file-system" page.
    2. Enable CSS and JS aggregation.
    3. Clear cache

  • ๐Ÿ‡บ๐Ÿ‡ธUnited States Coop920

    Currently on 10.1.4 and js aggregation is not working. Tried techniques above but to no success.

  • ๐Ÿ‡ธ๐Ÿ‡ชSweden emilcarpenter


    The explnation by voleger โ†’ in #19 ๐Ÿ’ฌ Aggregation not working css and js cache directories not being created Postponed: needs info was applicable in my case also, but with Apache 2.4.58 fcgi Docker container, instead of Nginx, and newly installed (not upgraded) Drupal 10 (10.2.1) with PHP 8.2.14 FPM/FastCGI in another container.

    The solution was to add these lines into the Apache virtual host:

    RewriteRule ^/(.*)$ fcgi://drupal-php-fpm:9000%{REQUEST_URI} [P,QSA,L]

    Discussion about this method:


    For someone unable to change server configuration:

    1. Installing and enabling the Advagg module makes the site work without the config change for the server.
    2. The aggregate CSS and JS boxes must be unchecked.
    3. The caches must be rebuilt with Advagg installed for the changes to take effect.

    So, nothing to do with Drupal configuration nor Drush nor file/folder permissions.

  • ๐Ÿ‡บ๐Ÿ‡ธUnited States darrell_ulm

    For me it was solved by this: ๐Ÿ› Deprecate system.performance stale_file_threshold Fixed

    drush cdel system.performance
    drush cdel system.performance stale_file_threshold
    drush cdel system.performance reponse
  • ๐Ÿ‡ฉ๐Ÿ‡ฐDenmark ressa Copenhagen

    Should it be response?

  • ๐Ÿ‡บ๐Ÿ‡ธUnited States momolarson

    My issue seems to be similar in that when I enable Aggregation, I get the 404 errors. I have tried all the techniques here, I have ensured my folders are writable. The only exception is that I do not use nginx, I am using Apache.

    If I set "file_assets_path" to a valid, writeable path, when I inspect the css and js folders, they are empty: no files get written and I obviously get 404 errors.

    What is interesting is that I am able to solve this issue by adding an invalid path to my $settings['file_assets_path'].

    For instance, if I set $settings['file_assets_path'] = 'sites/default/files/optimized', I get errors. If I change that path to something invalid, such as $settings['file_assets_path'] = 'sites/defualt/files/optimized' Everything works! If I search for the files, I find them in the public directory: "sites/default/files/css" or "sites/default/files/js".

    However, when I look in my inspector, the URLS to the CSS/JS files will include the invalid URL, however, it's still accessible.


    find . -type f -name 'js_FBvJqd58OZT6lWslaaBedWyR2bsFZRC8pPvEoK4Rh6Q.js'

    I have not been able to determine why this is the case, but it is the only consistent way to make this work. If there are suggestions on how to debug, I would appreciate that.

  • ๐Ÿ‡ซ๐Ÿ‡ทFrance FMB Perpinyร , Catalonia, EU
  • ๐Ÿ‡บ๐Ÿ‡ธUnited States momolarson

    Thank you for responding, my issue is isolated to a box and is not repeatable in my production environment so I think we can disregard this.

  • ๐Ÿ‡บ๐Ÿ‡ธUnited States SocialNicheGuru

    I like so many others am now experiencing this. The patch above did not fix the issue.

  • ๐Ÿ‡บ๐Ÿ‡ธUnited States SocialNicheGuru

    I had to set public_base_url in my settings.php file and aggregation worked

  • ๐Ÿ‡ซ๐Ÿ‡ทFrance louis-cuny

    In my case, I found memory_limit issues in apache logs
    Setting to memory_limit = -1 is fixing the issue for example

  • ๐Ÿ‡ฆ๐Ÿ‡นAustria nofue

    Running two servers, the production server runs on Debian 10, recently upgraded to 11, and dev runs on Debian 12.

    The setup of both systems is (almost) identical -- Prod srv configures sites using a site management tool, dev srv was configured manually. Everything Drupal works identical at first glance, but there's one major difference which causes the problem reported above. First some background information:

    File permissions are the same on prod & dev, following the drupal file permission guideline, set by some script

    drwxrw-r-x [siteuser] [apacheuser] [dirname] and
    -rw-rw-r-- [siteuser] [apacheuser] [filename]

    On production, Drupal changes ownership on directories and files to [siteuser][siteuser] when writing.
    On dev, the ownership is set to [apacheuser][apacheuser].

    By this, files become inaccessible for [siteuser] -- and as command line operations such as drush, are run as [siteuser], file access errors occur.

    The same holds true for any directory or file written by Drupal, such as images and directories in public://

    As the only difference between these installations is the setup of the vhost structure in Apache, I suppose there's the cause of this problem is found. Sadly I lack experience in setting up Apache2 sites, hence I have to try to find the differences between the site-available/[siteuser].conf files.

    However, I think this is not (directly) a Drupal problem, but an issue with the most basic settings of Apache vhosts.

    The workaround is to add [siteuser] to the group www-data.

    # sudo usermod -a -G www-data [siteuser]

    I'm going to research the proper Apache settings, but for the time being this seems to work.

  • ๐Ÿ‡ฆ๐Ÿ‡นAustria nofue

    OK, as promised in #63, I investigated the issue (at least as how I was affected) and I was right with my assumption. To help you to understand the issue, here's the background of all this:

    Apache runs as user: www-data and group: www-data. This work in small (dev) environments, but not in public server hosting environments, as you have top protect clients from getting their data accessed by other clients. Hence every instance of Apache starts as root and once the proper vhost is determined, it becomes that user -- quite common f.e. 'web1'. Once files are written by Apache, they have [siteuser]:www-data as owner:group attached.

    In shared hosts, the server admin put everything in order, but if you have set up your own Apache on a local machine, trying to use that thing to work an several websites, you're likely to also set up vhosts. Whenever you work within such a virtual "client space", you should become the proper user, web1, f.e. When you (as web1) create a file (touch myfile.txt) it will have web1:web1 as owner:group. If you run drush in this webspace, it will run as web1:web1. If you access the site through Apache, it will run as www-data:www-data. And then drush will complain about missing file access rights โ€ฆ

    Now let's solve the issue (if you use Apache2, of course). To make use of this recipe, you have to have root/sudo access to your webserver.

    Check if Apache has mpm_itk_module installed (# apache2ctl -M |grep mpm_itk)
    If mpm_itk_module is missing
    check if the mod has been already installed: ls -lha /etc/apache2/mods-available/ |grep mpm_itk
    if it's there, enable it using a2enmod mpm_itk.load, then restart Apache (on Debian/Ubuntu et al.: systemctl restart Apache2)
    if it's NOT there, search for mpm-itk and how to install it on your version of Linux/Apache2, โ€ฆ and then restart this procedure.
    in any case, check if it's enabled and running using (# apache2ctl -M |grep mpm_itk)

    When it mpm-itk is working, use your favorite editor to edit /etc/apache2/sites-available/[your virtual host file] (f.e. web1.conf)
    There should be a line
    DocumentRoot "/var/www/[siteuser]/htdocs/[drupal project]/[web base]"
    Add this line beneath DocumentRoot โ€ฆ:
    AssignUserId [siteuser] www-data
    Repeat for every in this file.

    Here's what the final thing look like with a server 'playground.lan', a siteuser 'web1' and Apache being in group www-data:

    <VirtualHost [your ip]>
        ServerName playground.lan
        DocumentRoot "/var/www/web1/htdocs/playground/web"
        AssignUserId web1 www-data

    Once you're done, save the .conf file and check it's syntax using apache2ctl -t
    If the result is Syntax OK, restart Apache.
    In Drupal, clear the cache using the UI, and now drush should work without complaining about missing file access permissions.
    Hope this helps your issue.

Production build 0.61.6-2-g546bc20