Gleich zwei schwere Dinger: die WordPress-Fehlermeldungen „Ist das übergeordnete Verzeichnis durch den Server beschreibbar?“ und „Aktualisierung fehlgeschlagen: Plugin-Aktualisierung fehlgeschlagen.“
Man möchte Bilder in die Medienübersicht laden oder einfach nur die Plugins oder Themes aktualisieren und plötzlich hagelt es diese beiden WordPress-Fehlermeldungen. Beim Versuch in die Medienübersicht etwas zu ergänzen erscheint zunächst die Meldung:
„Ist das übergeordnete Verzeichnis durch den Server beschreibbar?“
Und beim Versuch Plugins o.ä. Interna auf den neusten Stand zu bringen, gibt es nur den Hinweis:
„Aktualisierung fehlgeschlagen: Plugin-Aktualisierung fehlgeschlagen.“
Alle Webtipps scheinen nicht zu helfen, also etwa:
- safe mode auf off setzen (hat man längst)
- in die wp-config.php die Zeile define( ‚FS_METHOD‘, ‚direct‘ ); aufzunehmen
- die Ordnerrechte auf 755, 775 oder auch auf 777 zu setzen
- sicherzustellen, dass alle Daten www-data gehören
… und einige andere Gassenhauer.
Was ist es dann???
Die obigen Tipps sind alle bei einer einfachen Konfiguration ja gar nicht übel. Wenn sie geholfen haben, liegt wohl eine klassische einfache Installation vor: irgendein Linux, Apache als Webserver oder eine ähnliche Virtualisierung vom Hoster.
Das hier Problem entsteht meist in einer, hm, Gemengelage. Etwa wenn verschiedene Installationswege unglücklich vermischt wurden und ein weiterer Konfigurationsakteur mitspielt, z.B. Plesk. Konfigurationstools wie Confixx, Plesk oder andere wollen die regelmäßig unsäglich unergonomische Bedienbarkeit mit megakryptischen Kommandos von Webservern durch Menüs und klickbare Elemente etwas bedienbarer machen. Gleichzeitig sollen noch Multisite-Installationen unter eine Haube gebracht werden: wenn schon einfach, warum nicht gleich ein duzend Websites unter einer Server bringen?
Dazu muss aber getrickst werden. Eigentlich gibt es z.B. für die PHP-Installation nur eine Konfigurationsdatei namens php.ini auf einem Webserver und da steht (wieder:) eigentlich global drin, wieviel Speicher in welcher Zeit zur Verfügung stehen darf und vieles mehr. Bei mehreren Sites auf einem System will man nun einer Site vielleicht mehr Speicher oder Rechenzeit und einer anderen weniger zuweisen. Daher muss man dem System jetzt schon etwas künstlich in unterschiedlichen Kontexten (also für die unterschiedlichen Sites auf so einem Server) unterschiedliche Konfigurationen vorspielen.
Wenn man dann zwischendurch per FTP/SSH am Plesk-System vorbei als root/admin/Superuser/Weltherrscher oder einer ähnlichen Rolle Dateien aktualisiert hat, erhält man einen schönen Mischmasch im Dateisystem: Dateien gehören dann einem dieser Admins, die vielleicht in der Gruppe www-data (oder einer ähnlichen Webserver-Rechtegruppe) sind oder auch nicht oder dem User mit dem jeweiligen Login. Die Webserver wie Apache und deren Konfigurationsaufsätze wie Plesk verlassen sich aber streng darauf, dass die unter ihrer Hoheit abgelegten Dateien und Ordner sowohl
- von der Eigentümerschaft sowie
- von den hinterlegten Rechten her
recht streng den Vorgaben entsprechen. Da kann schon eine als root mit WinSCP – also an der Plesk-Ebene vorbei – hin- und hergeschobene Datei genügen, die dann eben plötzlich root gehört und nicht mehr dem Plesk-Nutzer. Tückischerweise merkt man die Folgen womöglich eine ganze Weile nicht – vielleicht nutzt erst an anderes Plugin den Code und das auch erst nach dessen Update Wochen später. Dann hält man natürlich erst einmal dieses Plugin oder Update für den Schuldigen – denn danach war ja Alles im Eimer. Das muss aber eben nicht der Fall sein – ein völlig korrektes Update kann ebenso den schon lange schlafenden Fehler „geweckt“ haben.
Geht das wieder weg?
Im Kern muss man folgende Dinge hinbekommen:
- Plesk benötigt, dass die Dateien den Besitzer haben, der für diese Domain als Systemnutzer hinterlegt ist (der Name, den man z.B. auch zum Einloggen in Plesk nutzt, um an der Domain etwas konfigurieren zu können – möglichst nicht der Plesk-Admin sondern ein von dieser Rolle erzeugter Plesk-Nutzer). Wer schon Low-Level-Apache administriert hat, muss vorsichtig sein – der dort übliche technische Standarduser namens www-data ist es nicht. Wer die Dateien aus dieser Gewohnheit wie SSH/SCP diesem User zuordnet, hat erst einmal einen satt verschlimmbesserten Zustand geschaffen. Der User existiert zwar unter den meisten Linuxen, damit haut man Plesk aber die Beine nur völlig weg.
- Plesk benötigt eigentlich immer, dass die Dateien in der Gruppe psacln sind.
- Plesk benötigt eigentlich immer, dass die Ordner in der Gruppe psaserv sind.
- Plesk benötigt eine bestimmte Rechtekonfiguration. Hier gibt es zwar einen bestimmten Freiraum. Es gilt aber: soviel wie nötig, nicht mehr. Um auszuschließen, dass hier irgendeine Tür zu fest zu ist, gibt es auch hierfür eine Skript-Zeile.
Also – es geht los. Für den Plesk-Fall, bekommt man die Datei-Eigentümerschaft und die benötigte Rechte-Struktur so wieder hin:
- via Putty einloggen um Linux-Befehle ausführen zu können
Die Befehle:
- chown -R [user]:psacln /var/www/vhosts/[domain.xyz]/httpdocs
- chown [user]:psaserv /var/www/vhosts/[domain.xyz]/httpdocs
- find . –type d –exec chmod 755 {} \; # Verzeichnisrechte: rwxr-xr-x
- find . –type f –exec chmod 644 {} \; # Dateirechte rw-r–r–
Zuletzt:
- Ordner wp-content und den darin enthaltenen Ordner uploads auf 775 setzen
Natürlich ohne Gewähr und Garantie – solche Tipps nutzt jeder auf eigene Gefahr. Bei mir war’s das. Ich schreibe diesen Absatz aber auch, weil ich bei den Recherchen doch auch auf Tipps-Seiten gelesen habe, dass der Autor angemaunzt wurde, weil ein Tipp einen ungewollten Nebeneffekt gegebenenfalls zzgl. zum ausgebliebenen Haupteffekt hatte. Abhängig von der Wichtigkeit einer Site gehört ein Backup zu solchen Arbeiten dazu – und wer solche Admin-Tätigkeiten macht, sollte auch grob wissen, was man macht. Wem das nicht klar ist, der sollte besser nicht administrieren. Wer einfach Zeilen abhackert, die er gar nicht versteht und dann hinterher Schuldige sucht, sollte eher im Vorfeld Fachleute beauftragen.