• Gelöst snjlscmi

    (@snjlscmi)


    Hallo zusammen!

    Ich habe trotz tagelanger Recherche nur Tipps zu meinem Problem gefunden, die mir leider nicht weiter helfen:

    Ich habe eine wordpress-Installation auf einem Raspberrypi2 laufen. Die lief (für das, was der Pi2 an performance bietet, wie geschmiert). Aber musste ich den Pi2 leider neu aufsetzen, konnte aber vorher alle Datenbanken (also auch die, um die es bei diesem Topic geht) backuppen, sowie auch die Dateien des Frontends meiner WordPress Umgebung.
    Nach Neuinstallation von Null habe ich meine Seite wieder zum Laufen gebracht. Ich kann Dateien in die Mediathek hochladen, ich kann neue Seiten/Beiträge anlegen alte Seiten/Beiträge bearbeiten, das klappt alles.

    Was einfach nicht funktionieren will, ist das Updaten von Plugins oder WordPress selbst, sowie die Installation neuer Plugins. Ich komme zwar an das Document-Root ran, aber ich will Plugins wie vorher updaten, und nicht per Hand in dem Installationsverzeichnis rumwurschteln.

    Technische Detials:

    • Raspberry Pi 2 mit Raspbian GNU/Linux 9 (stretch)
    • Auch wenn das zugriffstechnisch ein Verbrechen ist, hat der Ordner wp-content die Rechte 777, sowie die Unterordner plugins und uploads (davon auch die Unterordner). Zumindest soviel weiß ich: mit 775 auf der Mediathek (also Ordner 2019 in uploads) kann ich nix hochladen, mit 777 schon, aber 777 hilft nicht beim Ordner plugins, da kann ich trotzdem nicht updaten (wozu WordPress ja in den Ordner schreibt).
    • Der Besitzer des Ordners 2019 in uploads ist julian:julian, also gehört meinem User am Pi
    • Der Besitzer des Ordners plugins ist julian:julian
    • Ich hatte den Besitzer des Ordners plugins auch testweise auf www-data:www-data
    • Der verwendete Webserver ist nginx

    Man sieht also, obwohl der Zugriff auf plugins genauso geregelt ist wie der auf 2019 (also auf die Mediathek), kann ich in der Mediathek hochladen, aber mit plugins kann ich nix über das Webinterface verwalten.

    Sind die Rechte vielleicht gar nicht das Problem, sondern ein ftp- oder sftp-Zugang, den ich mit der neuen Installation einrichten muss?

    Das habe ich probiert – ohne Erfolg (das tmp-Verzeichnis zusammen mit dem Eintrag in der config-Datei hilft nix, und cache-Plugin habe ich zZ keines installiert): https://redrice.biz/verzeichnis-konnte-nicht-angelegt-werden/

    Vielen Dank im Voraus für die Hilfe, falls weitere Infos benötigt werden, so lasst es mit bitte wissen.

    VG
    Julian

    Ey ich dreh noch durch: debugging geht auch nicht, obwohl auf true in der wp-config.php gesetzt, die debug.log per Hand angelegt, und Rechte 777 gesetzt. Plugin-Update versucht, scheitert, aber die debug.log ist leer…

    • Dieses Thema wurde geändert vor 5 Jahren, 8 Monaten von snjlscmi.
    • Dieses Thema wurde geändert vor 5 Jahren, 8 Monaten von snjlscmi. Grund: Debug-Modus versucht

    Die Seite, für die ich Hilfe brauche: [Anmelden, um den Link zu sehen]

Ansicht von 3 Antworten – 1 bis 3 (von insgesamt 3)
  • Die Verzeichnisse, in denen per Webinterface geschrieben werden soll, muss dem Nutzer gehören, unter dem der Webserver läuft, also www-data:www-data.
    Ich weiß vom apache2, dass dieser seinen Dienst verweigert, wenn die Verzeichnisrechte zu großzügig (777) gesetzt sind, vielleicht ist das bei nginx auch so.
    Was steht im Log vom nginx?

    Thread-Starter snjlscmi

    (@snjlscmi)

    Hallo hupe13,

    Erst einmal danke für deine Antwort! Im logfile von nginx steht dazu leider überhaupt nichts drin. Also ich versuche einen Plug and zu updaten, und danach wird trotzdem nichts dazu passendes in die error Datei eingetragen. Generell funktioniert das error logging bei mir beim Webserver aber, also die Datei ist nicht leer.

    Also zumindest auf dem Ordner Plugins hatte ich den Eigentümer auch schon auf www-data. bevor ich hier wild irgendwelche Eigentümer ändere:
    schlägst du vor, der kompletten WordPress-Installation den Eigentümer www-data zu geben? strengere zugriffsrechte bringen zumindest nichts, mit 775 zb komme ich trotzdem nicht weiter.

    Thread-Starter snjlscmi

    (@snjlscmi)

    Gelöst:

    wie doof, ich musste lediglich www-data:www-data zum Eigentümer vom webroot vom nginx geben. Anscheinend war da irgend ein Ordner dabei, wo der Benutzer noch keine Rechte hatte:

    sudo chown -R www-data:www-data /usr/share/nginx/www/

    Das war’s, Update geht!

Ansicht von 3 Antworten – 1 bis 3 (von insgesamt 3)
  • Das Thema „Rechteproblem?! Akt. fehlgeschl.: Verzeichnis konnte nicht angelegt werden.“ ist für neue Antworten geschlossen.