8

Using composer with Drupal (7, 8 & 9), composer require drupal/<package-name> returns the following error.

Installation failed, reverting ./composer.json to its original content.

[RuntimeException]
Could not delete web/sites/default/default.services.yml

How can I fix this error?

Improve this question
1
  • 1
    note to others: be aware of the security implications of the answers proposed so far as described in comments – Kay V Jul 5 '20 at 0:54
9

Make your "local" machine work as intended, and maintain the security of your live site.

Given that you should only be using composer require on your local machine, this approach will fix the issue on your local machine. The default .gitignore will limit the change to your local.

Don't make this change to settings.php, since you don't want to affect other instances, especially PROD.

Steps

  1. enable settings.local.php (here are the instructions from the docblock in settings.local.php):
 * To activate this feature, copy and rename it such that its path plus
 * filename is 'sites/default/settings.local.php'. Then, go to the bottom of
 * 'sites/default/settings.php' and uncomment the commented lines that mention
 * 'settings.local.php'.
 *
 * If you are using a site name in the path [... read about exceptions in file]

  1. set file permissions to allow user and group to write to the file on your local machine:

    $ chmod ug+w {name_of_docroot}/sites/default

How this approach matches up with the established community approach

By default, settings.local.php contains the following line:

$settings['skip_permissions_hardening'] = TRUE;

This line tells Drupal not to reset permissions on the default folder only on your local, and allows you to work more smoothly with composer on your local without loosening permissions on any other copy of the codebase.

Improve this answer
2
  • Makes sense. You should only make changes to web/default/ on your local, so it's logical to keep local permissions that allow changes to that directory while continuing to 'harden' permissions everywhere else. – lacuna Jul 5 '20 at 1:04
  • credit to @robb-davis for chmod improvement included in this answer – Kay V Nov 7 '20 at 15:50
7

This command will fix it temporarily:

chmod u+w web/sites/default

But Drupal will harden permission again soon. To turn it off add this to settings.php:

$settings['skip_permissions_hardening'] = TRUE;

Source: https://www.drupal.org/docs/develop/using-composer/starting-a-site-using-drupal-composer-project-templates#s-troubleshooting-permission-issues-prevent-running-composer

Improve this answer
4
  • 1
    This answer adds some useful details - thanks for posting it. That said, naturally it doesn't seem like you'd want simply to turn off hardening as part of your generally applied solution. How about updating the answer to specify doing this in settings.local.php? – Kay V Jan 30 '20 at 11:59
  • How about to discuss axiom that permission hardening has some sence? What are realistic cases where it protects something? – Bobík Jul 6 '20 at 11:29
  • Having seen how hard the Drupal community works at determining and implementing best available security settings, I believe default features are good to preserve unless I have extensive expertise in the alternatives. Since much of Drupal QA assumes defaults, odds are even higher there's a big advantage in maintaining them. Whether this particular setting is extraneous, @bobik, I'm not qualified to take on, tho I certainly hear your point. Thanks for the follow-on discussion! – Kay V Jul 6 '20 at 18:20
  • Good point, usually I use the same argument. But if I see that anywhere in docs the reason is not properly described I am skeptical. In this case it seems also like some common created in ages of primitively secured shared hostings. I also can imagine a lot of attack vectors what will work even with hardening and none what hardening can stop on current good hosting. And if someone use some primitively secured hosting than this hardening is probably his less important problem. – Bobík Jul 7 '20 at 21:57
4

I think you need to use

chmod ug+w web/sites/default

Without the g (group write permission) twig can't create it's tmp directories in files/php/twig and the site will throw a warning.

Improve this answer
0

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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