I'm new to this community, and asking for help because I'm stuck on this problem, and cannot go past. I've also tried asking on StackOverflow, but with no luck so far.

My current setup:

  • Drupal 8.8.5
  • CentOS Linux release 7.5.1804
  • PHP 7.2.19 and HTTPD - Apache/2.4.6
  • Run user/group: apache:apache

The /admin/reports/status#warning admin page reports that "the sites/default/files directory is not writable. You may need to set the correct folder in the configurations of the File system page or change the permissions of the current folder so that it is writable."

Obviously, this leads to a number of errors:

Drupal\Core\File\Exception\FileException: Failed to unlink file 'public://css/css_Y3zRgmC0P7yIXk_w_H9qyrPs3aMkKRv44SMfupbSCMc.css.gz'. in Drupal\Core\File\FileSystem->delete() (line 340 of/var/www/html/project/core/lib/Drupal/Core/File/FileSystem.php).

Warning: unlink(/var/www/html/project/sites/default/files/css/css_Y3zRgmC0P7yIXk_w_H9qyrPs3aMkKRv44SMfupbSCMc.css.gz): Permission denied in Drupal\Core\File\FileSystem->unlink() (line 124 of /var/www/html/synergie/core/lib/Drupal/Core/File/FileSystem.php)

The specified file 'temporary://fileuJjxaE' could not be moved to 'public://js/js_FKKJ_OhNvc7muQ1i_fQS6OJmZLsZnRvVhbbPaVlNwb8.js'.

Permissions for the file cannot be set for sites/default/files/translations

Now, I'm not a full expert on Drupal, but I've already tried doing all the possible basic things that these situations require on a linux system:

  • Setting all 777 to /var/www/html/project/sites/default and subdirectories
  • Changing owner of the directory aforementioned
  • Manually debugging lines 124 and 340 of lib/Drupal/Core/File/FileSystem.php
  • Sudoing on "apache" user with sudo -s /bin/bash apache and try to create/delete files from the command line (and it works)
  • Writing custom scripts that run under apache:apache, outside Drupal, to see if they can manipulate public://. (they work)

I think the problem is not in the filesystem itself, because whatever combination of permissions doesn't work, I believe this problem is connected to Drupal itself.

Fact is, if I write a custom script to write/read/move files from/to the /var/www/html/project/sites/default/files, it just works. It doesn't work "from within" Drupal.

As said before, I'm not a expert of all the "under the hoods" of Drupal like file settings, admin settings, drush, so I'm asking to you to try and issue this problem, because it's driving me crazy. Spent the last 10+ hours watching the command line and not understanding what's happening.

Kind regards,


  • Welcome to Drupal Answers :) The scripts you’ve written to confirm the apache user has write permissions - are you executing them from a web request, not CLI, to ensure a fair test and that the web server just isn’t misconfigured?
    – Clive
    Commented Apr 25, 2020 at 12:24
  • Hi Mario, welcome here :-) Two things I can think of: 1) The apache isn't actually running as the 'apache' user. 2) apache isn't acutally in the group the user allowed to write to /var/www/html/project/sites/default/files/ Maybe it would be helpful if you share a screen shot of ls -la /var/www/html/project/sites/default and ls -la /var/www/html/project/sites/default/files
    – nhck
    Commented Apr 25, 2020 at 14:42

1 Answer 1



Find current mode of SELinux and temporarily shut it down. "#" is for comment and can be removed.

Getenforce # see current mode.

getsebool -a # find al boolean values

Sudo setenforce 0 # shut it down, but will be back at reboot.

Try your thing. If that’s cause, just add rule to allow locations like /var/www/your Docroot.

SElinux will come back with reboot so to add a permanent rules for /var/www/drupal-document-root.

I do the following. Line 2 will work but won't survive rename & restorecon (line 3 will survive such things).

 ls -dZ /var/www/html  # See SELinux context of 
 sudo chcon -R -t httpd_sys_content_t /var/www/html/drupal-document-root
 sudo semanage fcontext -a -t httpd_sys_content_t "/var/www/html(/.*)?" 

I have also done the following in the past to give apache write permission.

# Selinux allow httpd read & write to /var/www/html/my-project 
sudo chcon -R -t httpd_sys_script_rw_t /var/www/html/my-project/
sudo chcon -R -t httpd_sys_script_rw_t /var/www/my-Symfony-project/var/log/

SELinux references: https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/selinux_users_and_administrators_guide/sect-managing_confined_services-the_apache_http_server-types

Beside that, the following is what I do when I setup new site and run into this kind of thing.

1) cat /etc/http/http.conf | grep user , to see user Apache is running as 2) from the vhost file, check the document root Then follow it and make sure Apache can write to it 3) Check your docroot or Symlinks Post and show the following 1&2& then l would love to see Ls -al /document root that Apache is pointing to And output showing Apache user is in right group

Don't forget to reset your drupal permissions to the best practices after resolving the issue. look at 2nd answer of the following.

What are the recommended directory permissions?

Ps: assuming your not setting up multisite as few more things will be needed.

  • Hi @Salah-1, you definitely made my day! I wasn't expert on CentOS configuration, used 90% of all my time Debian distros... anyway, you pointed me in the correct direction, as I've read this: wiki.centos.org/HowTos/SELinux, and then I've launched the "restorecon -Rv /var/www/html/www.example.com/sites/default/" command, and everything appears to run as expected. In your field of expertise, what would you do for "extra checks" to be sure that everything will run smoothly?
    – Maurizio
    Commented Apr 26, 2020 at 9:19
  • @ Maurizio, glad it worked out. There are times, I forget and I’m doing PhPUnit tests and SELinux is culprit. Don’t forget to select the answer if it’s correct thing. I’ll post update to it later today for additional stuff.
    – salah-1
    Commented Apr 26, 2020 at 9:40
  • Updated the answers since SELinux will need rules to survice reboot. Other than that, you can reset permissions and watch drupal status report page for hints. You can also have drush and do site-installs or watch dog error msg listing etc.
    – salah-1
    Commented Apr 26, 2020 at 11:52

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.