We've recently had a few problems with our server, which seem to have been all patched up by myself, my host, and the cPanel team. However, since then we have been having problems with sites/default/files. The problems are happening on the active site running D6, and our dev site, running D7 in a subdirectory at the moment. I'm assuming the problems are related, so after I figure out how to fix one site, I'm sure it will be a similar fix for the other.

On the D7 site, when I save a piece of content, I get the message: The specified file temporary://filetLWqk4 could not be copied, because the destination directory is not properly configured

At admin/config/media/file-system, I'm seeing the error: The directory sites/default/files exists but is not writable and could not be made writable.

When clearing the cache, I get an error including: Warning: unlink(mysite/sites/default/files/js/wysiwyg/wysiwyg_tinymce_VxxRIlcaFmzHlghU8SsOGCZd5TC_PCxyhQAlqydMALE.js): Permission denied in drupal_unlink() (line 2197 of mysite/dev/includes/file.inc)

What I have read seems to indicate that this is the result of a permissions problem that people seem to have with some clean installs and server migrations. Neither of these cases apply to me, but I thought the solutions might. Most pages that I can find essentially recommend

chown -R www-data:www-data sites/default/files

and making sure that permissions are set to 755 or 775. I'm on centos, which uses apache instead of www-data, so I substituted it where appropriate, but I still have no luck.

I also just tried changing the permissions of sites/default/files to 777, and I'm still getting the error that it couldn't be written to.

Any ideas?

  • 1
    Do not set the permissions of sites/default/files to 777, that is a giant security hole.
    – jonpeck
    Commented Oct 29, 2013 at 18:23
  • I realize that. It's definitely not a permanent solution. I just wanted to see if that would fix the issue for troubleshooting purposes, which it didn't. That was also on the production site only.
    – Mrweiner
    Commented Oct 29, 2013 at 19:01
  • 4
    If you still have this issue, does (temporarily) disabling SElinux remove the problem? Do '''sudo setenforce 0''' ('''setenforce 1''' to re-enable). Commented Dec 2, 2014 at 18:20
  • try chcon -R -t httpd_sys_rw_content_t sites/default/files
    – Yuseferi
    Commented May 18, 2020 at 12:24

9 Answers 9


RHEL and Fedora (among others) may have SELinux security enable. This will mask whatever the regular Unix permissions are showing. If this is enabled and there is not a "rw" in the context for the files/ directory it will not be writable no matter which group, user or unix permissions are granted. To see these "hidden" settings:

ls -laZ sites/default

drwxr-sr-x. apache www unconfined_u:object_r:httpd_sys_content_t:s0 .
drwxr-xr-x. apache www unconfined_u:object_r:httpd_sys_content_t:s0 ..
-rwxr-sr-x. apache www unconfined_u:object_r:httpd_sys_content_t:s0         default.settings.php
drwxrwsr-x. apache www unconfined_u:object_r:httpd_sys_content_t:s0 files
-rwxr-sr-x. apache www unconfined_u:object_r:httpd_sys_rw_content_t:s0 settings.php

To change the settings on files/ so it is writable:

sudo chcon -R -t httpd_sys_rw_content_t files

When the install is done reset the context using the same command with the original "http_sys_content_t" context.

fyi - This command will also be necessary to enable writes when installing themes under the "all" directory.

  • 2
    thnx for this answer after struggling for hours I am finally able to get past this
    – mbaxi
    Commented Feb 12, 2016 at 13:03
  • SELinux doesn't have any effect until the Discretionary Access Controls (ACL) are cleared. Therefore, if the user or group has missing file/folder write permissions, SELinux doesn't even get consulted for write contexts.
    – ILMostro_7
    Commented Jul 25, 2016 at 17:36
  • chcon -R -t httpd_sys_rw_content_t sites/default/files worked for me.
    – Yuseferi
    Commented May 18, 2020 at 12:23

One way that may work for you is changing the group and make it group writable as below:

chgrp www-data sites/default/files
chmod g+w sites/default/files

As per drupal docs the correct permission for all files is 644, and for directories is 755.

Also check this: What are the recommended directory permissions?

  • Unfortunately I tried this already. It has not helped with the problem.
    – Mrweiner
    Commented Oct 29, 2013 at 19:07
  • Ankit, There is NO www-data group OR user on CENTOS 7. They are using apache. I have both the group and user as apache and I have the find set as people have pointed out... still no luck. I get the same darn errors that two of the directories are there but are not writable and the other two cannot be created because they are not writable. To me this is a serious flaw in the structure of the application. Not very flexible NOT adaptive to the various user environments since regardless the environment this seems to be a common issue. Commented Dec 2, 2016 at 15:44

Guys the problem is very simple... whith XAMPP on Linux the "daemon" user is the owner of all process apache, SQL, etc... then just change the owner from the instalation folder "drupal" to daemon.. chown -R daemon:daemon folderdrupal

Regards from Chile ;)


I would also check the File System configuration and the paths being set there:


  • I already have. It is set for sites/default/files. As I said above, that page is displaying the error of "The directory sites/default/files exists but is not writable and could not be made writable."
    – Mrweiner
    Commented Oct 29, 2013 at 18:13

How about we make this a bit more of a long-term solution? su -l to root, and run the following on your SElinux-enabled installation (these are from my Fedora box, sanitized for easier comprehension)

setsebool -P httpd_unified=0 httpd_enable_homedirs=1 httpd_read_user_content=1 \ 
httpd_can_network_connect_db=1 httpd_can_network_connect=1

# normal webstuff
semanage fcontext -a -t httpd_log_t "/home/USERNAME/dev/projects(/.*)/logs(/.*)?"
semanage fcontext -a -t httpd_user_content_t "/home/USERNAME/dev/projects(/.*)?"
semanage fcontext -a -t httpd_user_rw_content_t \ 

restorecon -R -F -v /home/USERNAME/dev/projects/



I was not able to make this work until I changed the owner and group of

/sites/default/files & /sites/default/settings.php

to apache:apache (CentOs 7) once I applied these settings everything worked perfectly


I ran into something similar upgrading packages on a development box from PHP 5.5 to 7.1. Possibly the new configuration overwrote what I had previously configured.

I have apache running with a different user group than what php-fpm was running with (php-fpm). I needed to change my php-fpm configuration to use a common group.


For CentOS/RockyLinux/RedHat/Fedora -

You need two commands, the chown apache not solely resolve the problem.

  1. chcon -R -t httpd_sys_rw_content_t sites/default/
  2. chown -R apache:apache /var/www/html/demodrupal/sites/default/

When addressing the issue where Drupal cannot write to files due to SELinux restrictions, the first step is to verify if SELinux is indeed active on your system. You can do this by executing the command sestatus.

If the output indicates that SELinux is enabled, you have the option to adjust the enforcement levels for specific domains without needing to disable SELinux system-wide.

For instance, if you discover that the SELinux policy is preventing your web server (such as Apache or Nginx, which commonly runs under the httpd_t domain type) from writing to certain files required by Drupal, you can alter the SELinux policy for this domain to be permissive. This adjustment allows operations that would otherwise be blocked by SELinux, thus facilitating Drupal's file management tasks without fully compromising the security model.

To set the httpd_t domain to permissive mode, use the command:

semanage permissive -a httpd_t

This command effectively instructs SELinux to log actions that would have been denied under enforcing mode for the httpd_t domain, without actually denying them. It's a targeted approach that helps maintain the security benefits of SELinux for the rest of the system while accommodating specific requirements of your Drupal installation.

Please see https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/selinux_users_and_administrators_guide/sect-security-enhanced_linux-introduction-selinux_modes

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.