9

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
  • 2
    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
11

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

Since you want to use composer require command only on non-production environments, the following steps affect only on the machines you deliberately set up. Drupal's recommended configuration will be preserved on all other machines, including production servers.

Don't make this change to settings.php to avoid having it on PROD or propagating it silently to other developers' machines.

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 to avoid resetting permissions on the default folder only on your local, and allows you to work more smoothly with composer on your local without weakening 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
5

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
0

The issue is due to write permission. I had resolved by following step.

chmod u+w sites/default
Composer Update
Composer require drupal/mail_safety
Improve this answer

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.