Error on drush cr

That looks like a file system permissions setup on your end.

Describe what you did to change permissions.

also getting this but for css files:

[warning] unlink(/var/www/html/drupal/web/sites/default/files/css/css_1z7ocSf16eu4BoccT48egFpGZBXEN9bc.css.gz): Permission denied FileSystem.php:124

also happening for two sites just updated to Drupal 10.

This is also occurring for me for two sites that I've updated to Drupal 10.
Both of them use Jenkins for deployment. At first I thought it was a conflict between the user running apache and the user running drush commands on the server, but I think something else changed.

As a workaround I've been calling these two commands before all cache clears:

'sudo chmod -R 777 /var/www/site.com/web/sites/default/files/css' || true
'sudo chmod -R 777 /var/www/site.com/web/sites/default/files/js' || true

This obviously is less than ideal and fragile, if a file gets cached between that call and cr it will still fail.
There does seem to be something up with the assets schema change cause this occurred for two separate sites as soon as I updated them to Drupal 10, both sites have been deploying for years before hand.

Here are the file permissions for the css files: -rw-rw-r-- 1 www-data www-data
They are the same for the js files.

I'm not sure what the permissions used to be, but the drush user used to be able to delete cached css files and js files.

To add some more detail, one of the hosts tried to set umask for those directories I think to allow the drush user to be able to delete, but they said cause it's a nfs mount point the umask settings were not taking affect.

I thought I had double checked that the deployment user for the other site was part of the www-data group, but it may not have been. I manually added the deployment user to www-data again and tested without the workaround and the deployment worked so I'll open a ticket with the other hosting provider to add the user to the apache group. Hopefully this helps other users with the same issue.

I still think something changed cause these deployments worked before the update to Drupal 10.

Drupal 10.1.0 introduced a new asset aggregation system. There have been a few issues resulting from that change.

Yeah the two sites that had issues are on 10.1. My question was more around did the asset change also change the permissions of the files that are generated.

It did affect things like that on some platforms and in some setups. Probably one of those recent issues I linked is about some aspect of that.

I had the same issue after updating from Drupal 9 to 10. I found that sites/default/files/css and sites/default/files/js had incorect ownership of www-data:www-data. I changed ownership to user:www-data to fix the issue.

Try turning off aggregation in the settings.php file

$config['system.performance']['css']['preprocess'] = FALSE;
$config['system.performance']['js']['preprocess'] = FALSE;

Or a workaround would be to manually search and delete the .js file.

I still have this issue. I see it is because for some reason Drupal is changing the ownership of the sites/default/files/js and sites/default/files/css directories back to www-data:www-data when it generates new aggregated css/js files. This is on my prod server so I need to keep aggregation enabled.

Can we migrate this issue to drush project?

No, because Drush issues are on Github. You can open an issue there and include the issue link in a comment here.

There is a related bug report for this where any further discussion should happen. I have updated the Issue summary with the comments that have possible solutions.

The Drupal Core issue queue is not the ideal place for support requests. The 'support request' option is there for filing support issues for contributed modules and themes. There are several support options listed on our Support page, including the Drupal Forums and Drupal Answers. There is also Drupal Slack. You may get better replies in one of those places.

I am closing this per the guidance in Handle or refer a support request in an issue.