it-swarm.com.de

Das Verzeichnis sites / default / files existiert, ist jedoch nicht beschreibbar und konnte nicht beschreibbar gemacht werden

Wir hatten kürzlich einige Probleme mit unserem Server, die anscheinend alle von mir, meinem Host und dem cPanel-Team behoben wurden. Seitdem haben wir jedoch Probleme mit sites/default/files. Die Probleme treten auf der aktiven Site auf, auf der D6 ausgeführt wird, und auf unserer Dev-Site, auf der D7 derzeit in einem Unterverzeichnis ausgeführt wird. Ich gehe davon aus, dass die Probleme zusammenhängen. Nachdem ich herausgefunden habe, wie eine Site behoben werden kann, bin ich sicher, dass es sich um eine ähnliche Lösung für die andere handelt.

Wenn ich auf der D7-Site einen Inhalt speichere, wird folgende Meldung angezeigt: Die angegebene temporäre Datei: // filetLWqk4 konnte nicht kopiert werden, da das Zielverzeichnis nicht ordnungsgemäß konfiguriert ist.

Unter admin/config/media/file-system wird der folgende Fehler angezeigt: Das Verzeichnis sites/default/files ist vorhanden, aber nicht beschreibbar und konnte nicht beschreibbar gemacht werden.

Beim Löschen des Caches wird folgende Fehlermeldung angezeigt: Warnung: Verknüpfung aufheben (mysite/sites/default/files/js/wysiwyg/wysiwyg_tinymce_VxxRIlcaFmzHlghU8SsOGCZd5TC_PCxyhQAlqydMALE.js): Berechtigung verweigert enthält/file.inc)

Was ich gelesen habe, scheint darauf hinzudeuten, dass dies das Ergebnis eines Berechtigungsproblems ist, das Menschen bei einigen Neuinstallationen und Servermigrationen zu haben scheinen. Keiner dieser Fälle trifft auf mich zu, aber ich dachte, die Lösungen könnten. Die meisten Seiten, die ich finden kann, empfehlen im Wesentlichen

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

und stellen Sie sicher, dass die Berechtigungen auf 755 oder 775 festgelegt sind. Ich bin auf Centos, das Apache anstelle von www-data verwendet, also habe ich es gegebenenfalls ersetzt, aber ich habe immer noch kein Glück.

Ich habe auch gerade versucht, die Berechtigungen von sites/default/files Auf 777 zu ändern, und es wird immer noch der Fehler angezeigt, in den nicht geschrieben werden konnte.

Irgendwelche Ideen?

5
Mrweiner

RHEL und Fedora (unter anderem) können die SELinux-Sicherheit aktivieren. Dadurch wird maskiert, was auch immer die regulären Unix-Berechtigungen anzeigen. Wenn dies aktiviert ist und im Kontext für die Dateien/das Verzeichnis kein "rw" vorhanden ist, kann es nicht geschrieben werden, unabhängig davon, welche Gruppen-, Benutzer- oder Unix-Berechtigungen erteilt wurden. So sehen Sie diese "versteckten" Einstellungen:

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

So ändern Sie die Einstellungen für Dateien/so ist es beschreibbar:

Sudo chcon -R -t httpd_sys_rw_content_t files

Wenn die Installation abgeschlossen ist, setzen Sie den Kontext mit demselben Befehl wie den ursprünglichen Kontext "http_sys_content_t" zurück.

fyi - Dieser Befehl ist auch erforderlich, um Schreibvorgänge bei der Installation von Designs im Verzeichnis "all" zu aktivieren.

17
chiddidilikahrn

Eine Möglichkeit, die für Sie funktionieren kann, besteht darin, die Gruppe zu ändern und sie wie folgt beschreibbar zu machen:

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

Gemäß drupal docs ist die korrekte Berechtigung für alle Dateien 644 und für Verzeichnisse 755.

Überprüfen Sie auch Folgendes: Was sind die empfohlenen Verzeichnisberechtigungen?

9
Ankit Agrawal

Leute, das Problem ist sehr einfach ... mit XAMPP unter Linux ist der "Daemon" -Benutzer der Eigentümer aller Apache-, SQL- usw. Prozesse ... dann ändern Sie einfach den Eigentümer vom Installationsordner "drupal" in "Daemon". R-Daemon: Daemon-Ordnerdrupal

Grüße aus Chile;)

2
user27301

Ich konnte diese Arbeit nicht machen, bis ich den Besitzer und die Gruppe von wechselte

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

zu Apache: Apache (CentOs 7) Nachdem ich diese Einstellungen angewendet hatte, funktionierte alles perfekt

0
Joe Laskowski

Ich habe auf einer Entwicklungsbox ähnliche Upgrade-Pakete von PHP 5.5 bis 7.1) gefunden. Möglicherweise hat die neue Konfiguration das überschrieben, was ich zuvor konfiguriert hatte.

Ich habe Apache mit einer anderen Benutzergruppe ausgeführt als mit php-fpm (php-fpm). Ich musste meine PHP-Fpm-Konfiguration ändern, um eine gemeinsame Gruppe zu verwenden.

0
mradcliffe

Wie wäre es, wenn wir dies ein bisschen mehr zu einer langfristigen Lösung machen? su -l zum Rooten und Ausführen der folgenden Schritte auf Ihrer SElinux-fähigen Installation (diese stammen aus meiner Fedora-Box und wurden zum besseren Verständnis bereinigt).

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/

erledigt.

0
WebDragon

Ich würde auch die Dateisystemkonfiguration und die dort festgelegten Pfade überprüfen:

YOUR_SITE_URL/admin/config/media/Dateisystem

0
Teknotica