Drupal installation is failing after the following steps on a Debian box (database is already created and privileges granted to specific user):

(user) $ composer create-project drupal/recommended-project myproject
# ... ask if it is OK to install composer/installers, drupal/core-composer-scaffold and drupal/core-project-message, answer Yes 
# ... emits 2 warnings about doctrine/reflection and webmozart/path-util being obsolete
(user) $ cd myproject
(user) $ composer composer require drush/drush
(user) $ drush site:install --locale=fr
# ... asks for MySql credentials
# ... displays admin user credentials.

Everything runs smoothly with no error messages, only the 3 questions and 2 warnings mentionned supra.

Yet, after running those commands, according to Drupal installation docs (https://www.drupal.org/docs/develop/using-composer/using-composer-to-install-drupal-and-manage-dependencies#s-install-drupal-using-the-command-line) the site should be accessible through-the-web. Yet, when I browse the configured path (DocumentRoot is set to the "web" directory) I got an unstyled page (same appearance than CSS not applying in drupal 8 site , but stylesheets href are set to "/").

If I take the through-the-web installation path instead of running Drush, then everything runs fine except for minor annoyances with permissions settings under 'web/sites/default'.

Comparing both "web" directories shows that (besides unsignificant differences due to different hashes) no "css", "js", "languages" nor "php" directories are created and populated under the Drush installed "web/sites/default/files" directory.

What am I doing wrong? I could find no help in Drupal documentation nor by googling around.

  • Drupal : 9.3.9
  • Composer : 2.2.9
  • Drush : 11.0.7

Thanks in advance

  • 3
    It's very likely to be permissions. You install with one user, then serve over the web with a different user who can't write to the folders the first user created as part of the install. Make sure www-data or equivalent can write to the files folders and the tmp folder
    – Clive
    Commented Mar 30, 2022 at 16:03
  • @Clive thank you for your comment but as stated in my question the problem only happens when the whole installation is run from the command line, obviously with the same user, hence no permission problem can possibly be involved. The common problem you describe relates to through-the-web install but this one runs fine in my case.
    – phep
    Commented Mar 30, 2022 at 18:41
  • 1
    How did you get an “unstyled page” through the command line? What you’ve described still strongly suggests a permission issue. Run sudo -u www-data touch docroot/sites/default/files/test.txt to make sure. If you get a perms error on that op, you’ve probably found the problem
    – Clive
    Commented Mar 30, 2022 at 18:44
  • @Clive I edited the question to try to make it clearer that the problem occurs when the installation is made with Drush invocation, not by going through "core/install.php". As stated, if I install by using the web interface I meet not substantial problems. Those happen when I use drush site:install instead. According to the documentation, running this command should equate to going the usual web process (I mean browsing to core/install.php, ... Is it more clear now?
    – phep
    Commented Mar 30, 2022 at 19:02
  • 2
    Drush does not create any JS or CSS or cache files, this happens on demand by visiting pages in the browser. And if those are not created on demand, it is almost certainly due permissions. And even the web install runs fine except for minor annoyances with permissions settings under 'web/sites/default'
    – Hudri
    Commented Mar 30, 2022 at 19:04

1 Answer 1


The folders you mentioned aren't generated by the site installation process, they're generated by a page request to the resulting Drupal site itself.

When you install through the UI, this happens:

  • Drupal gets installed
  • sites/default/files is created and owned by the web server (typically www-data)
  • You get redirected to the front end of the site, Drupal generates assets and tries to persist them to sites/default/files
  • The request is running as www-data, the folder is owned by www-data, so all good - files get created.

When you install through the CLI, it's slightly different:

  • Drupal gets installed
  • sites/default/files is created and owned by the user you ran drush as, which wouldn't typically be www-data (if it was, you shouldn't be having these problems).
  • You visit the site in a browser, Drupal generates assets and tries to persist them to sites/default/files
  • The request is running as www-data, but the folder is owned by your user, so no dice - files are not created.

High level, the answer is to make sure www-data can write to the sites/default/files folder after you install via the CLI. The Securing file permissions and ownerships docs have some suggestions on how you can accomplish this.

  • Could you please tell me exactly what you mean in the 3rd step of the CLI install process you describe when you say "You visit the site in a browser"? Do you mean any (site related) URL or some specific end of the install URL one? And in this case, I repeat my question : what's the use of the Drush path? Thank you anyway, I appreciate you help.
    – phep
    Commented Mar 30, 2022 at 19:40
  • I mean literally any URL on the front-end of the site, not a specific one. When CSS/JS aggregation is enabled (as it is by default after install), the aggregated files are generated on demand when a page is visited, and cached from then. Your current issue seems to be that the aggregated files can't be written, and the steps you've outlined to get to this point support that idea
    – Clive
    Commented Mar 30, 2022 at 19:52
  • Thank you for your patience. A pity such basic clue is absent from Drupal docs. I have to admit that I had hitherto never crossed the path of a webapp that waits for the very first non-targeted / non authenticated connection to complete its installation process ;-).
    – phep
    Commented Mar 31, 2022 at 8:35
  • It gets away with it because asset generation is supposed to be dynamic, it's not part of the installation process. But I get what you mean, it's confusing if you haven't done it a hundred times before
    – Clive
    Commented Mar 31, 2022 at 8:38

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.