Aggregation not working css and js cache directories not being created

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.

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

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 ( https://www.drupal.org/node/2888767 → ) are implemented. Also the tips from the issues from comment 2 have already been worked through, nothing helps unfortunately.

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

$ drush cache:rebuild
PHP Warning:  unlink(/var/www/html/website.com/public_html/web/sites/default/files/css/css_Dd8YCdHfaQEgt3dWdSVw94rP7EmTUdfBCOWw7Z_fzr8.css): Permission denied in /var/www/html/website.com/public_html/web/core/lib/Drupal/Core/File/FileSystem.php on line 124
 [error]  Failed to unlink file 'assets://css/css_Dd8YCdHfaQEgt3dWdSVw94rP7EmTUdfBCOWw7Z_fzr8.css'.

More possibly related issues? https://github.com/drush-ops/drush/issues/5728 and ✨ Generated scripts owner Fixed .

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

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.

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/website.com/public_html/web/
$ chown -R webuser:www-data .

Owner has been changed at some point:

$ ls /var/www/html/website.com/public_html/web/sites/default/files/
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

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.

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.

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/website.com/public_html/web/sites/default/
-rw-r----- 1 webuser www-data 8,9K Aug 10 12:35 default.services.yml
-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/website.com/public_html/web/sites/default/files
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

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.

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 https://www.drupal.org/docs/administering-a-drupal-site/security-in-drup... → and do run everyday tasks as webuser. I haven't had any problems so far, until Drupal 10.1.2.

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.

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.

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

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

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.

Figured out the cause of the issue. In my case it was outdated nginx preset configuration.
See https://github.com/wodby/nginx/blob/5.33.4/templates/presets/drupal10.co...

@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.

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.

Best,
Orkut

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.

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

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

Yes I had seen.

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

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;

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';

@mufaddal, what was your problem?

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

Thank you @OrkutMuratYılmaz ,

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

@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

@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.

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 → .

Thank you @ressa,

I'll verify the server permissions again.

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: https://www.drupal.org/project/drupal/issues/3368769 🐛 10.1.x breaks Nginx + PHP-FPM with too many redirects even when nginx config is changed Closed: works as designed

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: https://www.drupal.org/project/fast_404/issues/3373845 🐛 Fast404 prevents css/js assets from generating when aggregation is enabled on Drupal 10.1 Fixed

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
config:
  php: 8.1
  webroot: web
  via: nginx
...

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.

Best,
Orkut

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
www-data:siteuser
as per
https://www.drupal.org/docs/administering-a-drupal-site/security-in-drup... → 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
once.

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:
www-data:www-data
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
www-data:www-data
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.

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.

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

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

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

Thanks @yan solution #43 really helped!

Please check this comment 🐛 'ipless' is not a supported key. Active .

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

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

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

Solution

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:

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

Discussion about this method:
https://serverfault.com/questions/290784/what-is-apaches-equivalent-of-nginxs-try-files

Workaround

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.

For me it was solved by this:
https://www.drupal.org/project/drupal/issues/3410301#comment-15370309 🐛 Deprecate system.performance stale_file_threshold Fixed

drush cdel system.performance cache.page.use_internal
drush cdel system.performance stale_file_threshold
drush cdel system.performance reponse

Should it be response?

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.

/sites/defualt/files/js/js_FBvJqd58OZT6lWslaaBedWyR2bsFZRC8pPvEoK4Rh6Q.js?scope=footer&delta=20&language=en&theme=gtc_barrio&include=eJyNVMGS2yAM_SESTv2Admb31Jl-QkYG2WECiCKRnd2vr7BjZxP3kIMBvfcQQkh2lBJWhyeWGgraZTL8yYLJDsBoBiJRGMppgFoD2SnSAPHA8hlDnswkbmXuUufzd-Jpi6OK1tdWIB7BSbjiQfGLcREhC8SLhTI4OZQ2xODMNeAH23k8JvItonq4xe2giu3DaYjkLv1Qq98R_BWyQ48-CNUNlpZvMc_mhLniZuE4ohOTyaMdqaaNYAcRBYZ4144VZSCofp-feev3K16xSlAXB3XBD4yjGKFokuczb2BfP6aoCemFi8aApoCcV6KvZ6Ar7EfwE8rDThYQ5CVbWe6nzqbRoZ1aWOGbacYQBeuKLpZxlyWTP2zIamdlVm8r84pGz_b4a36pV9SYyhk48Evis6T4lqeQ8SV5SDC9plxefs7rHewp7y8N8szMhfi3kez2nKmGL-oV_nuO8pFdWuAZ453_Atqc75XSn3EMbuemYqIrvv83NKamTfOmVu-CXeUmZNak8OnjHDR6IYrK2NtsGt_Loq-PwVFmlbWuadWwXlBc2wpttbd23Vw9uT6itljBnz6FvLTY4w9jF2nPFf8DwHfSjw

find . -type f -name 'js_FBvJqd58OZT6lWslaaBedWyR2bsFZRC8pPvEoK4Rh6Q.js'
returns
./web/sites/default/files/js/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.

For multilingual websites using the Redirect module, it is worth checking this patch #3373123-39: Setting 'Enforce clean and canonical URLs.' breaks CSS aggregation on multilingual Drupal 10.1.x with browser caching enabled → .

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.

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

Updated ✨ Allow to validate Apache/Nginx configuration requirement for aggregation folder before enabling aggregation. Needs review
Please review, thanks

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

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

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 fix-permission.sh 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.

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.