16

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
    Commented Jul 5, 2020 at 0:54

4 Answers 4

Reset to default
25

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
5
  • 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
    Commented Jul 5, 2020 at 1:04
  • credit to @robb-davis for chmod improvement included in this answer
    – Kay V
    Commented Nov 7, 2020 at 15:50
  • The skip_permissions_hardening approach didn't work for me, while changing permissions did make it work as expected. I've used the workaround provided in the documentation. Nor sure why group write permission is needed as owner might generally be the user running update routines on the local system. A corresponding issue also mentioned the file-mapping approach, though I'm not sure what happens with changes.
    – Pjotr
    Commented Aug 17, 2021 at 9:35
  • I'm having the same problem on my remote server I get the message "Could not delete default.services.yml". But you are talking about a local change, how will this affect my remote problem? Or doesn't it and should I do something else?
    – Joost
    Commented Nov 11, 2022 at 9:28
  • hi @Joost - since I avoid making changes directly on a remote server (and I believe most of the drupal community feels similarly), I may not be familiar with your need. Can you make changes on a local copy then deploy those changes to your remote?
    – Kay V
    Commented Nov 14, 2022 at 18:27
17

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
5
  • 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
    Commented Jan 30, 2020 at 11:59
  • How about to discuss axiom that permission hardening has some sence? What are realistic cases where it protects something?
    – Bobík
    Commented Jul 6, 2020 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
    Commented Jul 6, 2020 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
    Commented Jul 7, 2020 at 21:57
  • This seems to be a good answer, though it seems to mention that permission fix will only be a temporary one. From what I've just experienced with a local Drupal 9 that had similar issues is that sides/default is missing the write permission for the owner, while contained files like default.services.yml seem to have it set. Just changing the permission for the local system should work just fine, with compose being able to make all the necessary changes. If that change is not welcome for the live environment, then an update script could add that temporarily and then remove.
    – Pjotr
    Commented Aug 17, 2021 at 9:46
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
1
  • Not sure why would the group permission be needed and it might be related to ownership of the files and directories. If the owner and the user running updates is the same, then group permissions shouldn't be required. Maybe it's worth mentioning.
    – Pjotr
    Commented Aug 17, 2021 at 9:49
0

The issue is due to write permission. I resolved it by running the following commands.

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 and acknowledge you have read our privacy policy.

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