Le répertoire sites / default / files existe mais n'est pas accessible en écriture et n'a pas pu être rendu accessible en écriture
Nous avons récemment rencontré quelques problèmes avec notre serveur, qui semblent avoir tous été corrigés par moi-même, mon hôte et l'équipe cPanel. Cependant, depuis lors, nous rencontrons des problèmes avec sites/default/files. Les problèmes se produisent sur le site actif exécutant D6, et sur notre site de développement, exécutant D7 dans un sous-répertoire pour le moment. Je suppose que les problèmes sont liés, donc après avoir compris comment réparer un site, je suis sûr que ce sera un correctif similaire pour l'autre.
Sur le site D7, lorsque j'enregistre un élément de contenu, j'obtiens le message: Le fichier spécifié temporaire: // filetLWqk4 n'a pas pu être copié, car le répertoire de destination n'est pas correctement configuré
Dans admin/config/media/file-system, je vois l'erreur: Le répertoire sites/default/files existe mais n'est pas accessible en écriture et n'a pas pu être rendu accessible en écriture.
Lors de l'effacement du cache, j'obtiens une erreur comprenant: Avertissement: dissociation (mysite/sites/default/files/js/wysiwyg/wysiwyg_tinymce_VxxRIlcaFmzHlghU8SsOGCZd5TC_PCxyhQAlqydMALE.js): autorisation refusée dans drupal_unlink (mysite /) (21) comprend/fichier.inc)
Ce que j'ai lu semble indiquer que c'est le résultat d'un problème d'autorisations que les gens semblent avoir avec certaines installations propres et migrations de serveurs. Aucun de ces cas ne s'applique à moi, mais je pensais que les solutions pourraient le faire. La plupart des pages que je peux trouver recommandent essentiellement
chown -R www-data:www-data sites/default/files
et m'assurer que les autorisations sont définies sur 755 ou 775. Je suis sur centos, qui utilise Apache au lieu de www-data, je l'ai donc remplacé le cas échéant, mais je n'ai toujours pas de chance.
J'ai également essayé de modifier les autorisations de sites/default/files à 777, et je reçois toujours l'erreur à laquelle il n'a pas pu être écrit.
Des idées?
RHEL et Fedora (entre autres) peuvent avoir la sécurité SELinux activée. Cela masquera les autorisations Unix habituelles. Si ceci est activé et qu'il n'y a pas de "rw" dans le contexte des fichiers/répertoire, il ne sera pas accessible en écriture quel que soit le groupe, l'utilisateur ou les autorisations Unix accordées. Pour voir ces paramètres "cachés":
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
Pour modifier les paramètres des fichiers/pour qu'il soit accessible en écriture:
Sudo chcon -R -t httpd_sys_rw_content_t files
Une fois l'installation terminée, réinitialisez le contexte à l'aide de la même commande avec le contexte "http_sys_content_t" d'origine.
fyi - Cette commande sera également nécessaire pour activer les écritures lors de l'installation des thèmes sous le répertoire "all".
Une façon qui peut fonctionner pour vous est de changer le groupe et de le rendre accessible en écriture comme ci-dessous:
chgrp www-data sites/default/files
chmod g+w sites/default/files
Selon documents drupal l'autorisation correcte pour tous les fichiers est 644 et pour les répertoires est 755.
Vérifiez également ceci: Quelles sont les autorisations de répertoire recommandées?
Les gars, le problème est très simple ... avec XAMPP sous Linux, l'utilisateur "daemon" est le propriétaire de tous les processus Apache, SQL, etc ... puis changez simplement le propriétaire du dossier d'installation "drupal" en daemon .. chown - Démon R: dossier démondrupal
Cordialement du Chili;)
Je n'ai pas pu faire ce travail jusqu'à ce que je change de propriétaire et de groupe de
/ sites/default/files & /sites/default/settings.php
à Apache: apache (CentOs 7) une fois que j'ai appliqué ces paramètres, tout fonctionnait parfaitement
Je suis tombé sur quelque chose de similaire pour mettre à jour des packages sur une boîte de développement de PHP 5.5 à 7.1. Peut-être que la nouvelle configuration a écrasé ce que j'avais précédemment configuré.
J'ai Apache exécuté avec un groupe d'utilisateurs différent de celui avec lequel php-fpm était exécuté (php-fpm). J'ai dû changer ma configuration php-fpm pour utiliser un groupe commun.
Et si nous en faisions un peu plus une solution à long terme? su -l pour rooter et exécuter ce qui suit sur votre installation compatible SElinux (celles-ci proviennent de ma boîte Fedora, aseptisées pour une meilleure compréhension)
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/
terminé.
Je vérifierais également la configuration du système de fichiers et les chemins d'accès qui y sont définis:
YOUR_SITE_URL/admin/config/media/file-system