The directory sites/default/files exists but is not writable and could not be made writable

Question

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?

Answer 1

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.

Answer 2

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?

Answer 3

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 ;)

Answer 4

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

YOUR_SITE_URL/admin/config/media/file-system

Answer 5

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(/.*)?"
#Drupal
semanage fcontext -a -t httpd_user_rw_content_t \ 
"/home/USERNAME/dev/projects(/.*)/www/sites/default/files(/.*)?"


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

done.

Answer 6

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

Answer 7

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.

Answer 8

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/

Answer 9

In ISPManager` settings of your site change php operating mode from "Apache Module" to "FastCGI (Apache)"

Answer 10

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