./sites/default/files directory permission check is incorrect during install AND status report (affects Docker on Windows)

Created on 18 October 2010, about 14 years ago
Updated 23 January 2024, 10 months ago

Problem/Motivation

The install.php script and the "Reports > Status" Report both check for the files directory to have read/write permissions, but they should be checking for read/write/execute permissions instead.

This can cause various hard-to-troubleshoot permission-related errors with the files directory, including on Docker environments.

Steps to reproduce

  • Drupal is already installed
  • (goof up permissions) chmod 766 ./sites/default/files
  • Click Reports > Status Report
  • File System is green (should be red here, directory is not executable). No big deal yet
  • Click on Configuration > Performance
  • Click either Aggregate checkboxes under Bandwidth optimization or both
  • Clear all caches
  • You'll notice the CSS problem right away if that's what you selected to aggregate

Results

The specified file temporary://file6GnL0E could not be copied, because the destination directory is not properly configured. This may be caused by a problem with file or directory permissions. More information is available in the system log.

Proposed resolution

Install.php and Reports > Status should check for read/write/execute permissions (x77) on the directory in question

Remaining tasks

  • The patch needs to be rerolled for the latest version of Drupal 8.
  • It is not possible to add a reliable automated test for this issue.
<!-- See https://drupal.org/core-mentoring/novice-tasks for tips on identifying novice tasks. Delete or add "Novice" from the Novice? column in the table below as appropriate. Uncomment tasks as the issue advances. Update the Complete? column to indicate when they are done, and maybe reference the comment number where they were done. -->

Related issues

User interface changes

  • None known.

API changes

Two functions will be added to the API:

  • file_directory_is_writable($uri)
  • drupal_is_executable($uri)

Original report by [mlehner616]

The install.php script checks for the files directory to have read/write permissions (x66), should be checking for read/write/execute instead (x77).
If the files directory is created with just read/write permissions, turning on caching/compression strips off CSS and displays errors regarding temporary files.

Install.php should check for this correctly, as well as the status report script.
Basically these two scripts don't care if execute permissions are set on ./sites/default/files

This may be a critical issue but I'll let someone more technical triage this one.
Tested multiple times and was able to reproduce this behavior:

Scenario 1

Drupal is already installed
(goof up permissions) chmod 766 ./sites/default/files
Click Reports > Status Report
File System is green (should be red here, directory is not executable). No big deal yet
Click on Configuration > Performance
Click either Aggregate checkboxes under Bandwidth optimization or both
Clear all caches
You'll notice the CSS problem right away if that's what you selected to aggregate

Here are the errors:
The specified file temporary://file6GnL0E could not be copied, because the destination directory is not properly configured. This may be caused by a problem with file or directory permissions. More information is available in the system log.
The specified file temporary://fileNY1O4m could not be copied, because the destination directory is not properly configured. This may be caused by a problem with file or directory permissions. More information is available in the system log.
The specified file temporary://fileSsnd94 could not be copied, because the destination directory is not properly configured. This may be caused by a problem with file or directory permissions. More information is available in the system log.
The specified file temporary://fileV3PZdN could not be copied, because the destination directory is not properly configured. This may be caused by a problem with file or directory permissions. More information is available in the system log.
The specified file temporary://fileSFTvjv could not be copied, because the destination directory is not properly configured. This may be caused by a problem with file or directory permissions. More information is available in the system log.
The specified file temporary://fileLB2jpd could not be copied, because the destination directory is not properly configured. This may be caused by a problem with file or directory permissions. More information is available in the system log.
The specified file temporary://fileSKgNvV could not be copied, because the destination directory is not properly configured. This may be caused by a problem with file or directory permissions. More information is available in the system log.
The specified file temporary://file1KkKCD could not be copied, because the destination directory is not properly configured. This may be caused by a problem with file or directory permissions. More information is available in the system log.
The specified file temporary://fileCHUVJl could not be copied, because the destination directory is not properly configured. This may be caused by a problem with file or directory permissions. More information is available in the system log.
The specified file temporary://fileNcdmR3 could not be copied, because the destination directory is not properly configured. This may be caused by a problem with file or directory permissions. More information is available in the system log.

What's expected:
Install.php and Reports > Status Report should red flag the non-executable files directory (permissions must be 777)

Install.php actually does the same thing. It doesn't care that ./sites/default/files directory is 766 when it should be 777

πŸ› Bug report
Status

Needs work

Version

11.0 πŸ”₯

Component
File systemΒ  β†’

Last updated about 1 hour ago

Created by

πŸ‡ΊπŸ‡ΈUnited States mlehner616

Live updates comments and jobs are added and updated live.
  • Needs issue summary update

    Issue summaries save everyone time if they are kept up-to-date. See Update issue summary task instructions.

  • DrupalWTF

    Worse Than Failure. Approximates the unpleasant remark made by Drupal developers when they first encounter a particular (mis)feature.

  • Needs manual testing

    The change/bugfix cannot be fully demonstrated by automated testing, and thus requires manual testing in a variety of environments.

  • Needs backport to D7

    After being applied to the 8.x branch, it should be considered for backport to the 7.x branch. Note: This tag should generally remain even after the backport has been written, approved, and committed.

  • D8MI

    (Drupal 8 Multilingual Initiative) is the tag used by the multilingual initiative to mark core issues (and some contributed module issues). For versions other than Drupal 8, use the i18n (Internationalization) tag on issues which involve or affect multilingual / multinational support. That is preferred over Translation.

  • Needs tests

    The change is currently missing an automated test that fails when run with the original code, and succeeds when the bug has been fixed.

Sign in to follow issues

Comments & Activities

Not all content is available!

It's likely this issue predates Contrib.social: some issue and comment data are missing.

Production build 0.71.5 2024