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 Oct 29 '13 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 Oct 29 '13 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). – Michael Greisman Dec 2 '14 at 18:20
  • try chcon -R -t httpd_sys_rw_content_t sites/default/files – Yuseferi May 18 at 12:24

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.

| improve this answer | |
  • 2
    thnx for this answer after struggling for hours I am finally able to get past this – mbaxi Feb 12 '16 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 Jul 25 '16 at 17:36
  • chcon -R -t httpd_sys_rw_content_t sites/default/files worked for me. – Yuseferi May 18 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?

| improve this answer | |
  • Unfortunately I tried this already. It has not helped with the problem. – Mrweiner Oct 29 '13 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. – Thomas TEX Wilson Dec 2 '16 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 ;)

| improve this answer | |

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


| improve this answer | |
  • 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 Oct 29 '13 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/


| improve this answer | |

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

| improve this answer | |

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.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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