WordPress-Dateiberechtigungen auf CentOS7 erfordern sudo

Lesezeit: 4 Minuten

Benutzer-Avatar
GlückReis

Ich verwende WordPress auf meinem VPS mit CentOS 7 LAMP Stack. Ich bin gefolgt diese Anleitung Berechtigungen zu setzen, dh ich habe ausgeführt

sudo chown apache:apache -R *

um sicherzustellen, dass mein WordPress-Verzeichnis Eigentum von ist apache:apache.

Ich habe auch WordPress-Verzeichnis- und Dateiberechtigungen mit diesen Befehlen festgelegt:

find . -type d -exec chmod 755 {} \;

find . -type f -exec chmod 644 {} \;

(Ich musste den obigen Befehlen das Präfix voranstellen sudo)

Normalerweise verwalte ich den Server, indem ich mich über SSH anmelde myuserwo myuser gehört zu den apache Gruppe und die wheel Gruppe.

Ich habe 3 Probleme:

  1. Jeder Datei-CRUD-Befehl im WordPress-Verzeichnis erfordert immer noch, dass ich dem Befehl das Präfix voranstelle sudo, oder ich erhalte einen Berechtigungsfehler. Seit myuser gehört apache und apache das Verzeichnis besitzt, bin ich verwirrt, warum ich den Befehlen immer noch das Präfix voranstellen muss sudo.
  2. Ähnlich wie Problem 1, alle git Befehl wie a git pull erfordert, dass ich dem Befehl ein Präfix voranstelle sudo oder ich erhalte einen Berechtigungsfehler.
  3. Wenn ich versuche, Themendateien automatisch über meine WordPress-Dashboard-Weboberfläche zu aktualisieren, erhalte ich Berechtigungsfehler. Interessanterweise kann ich Plugins über das WordPress-Dashboard ohne Berechtigungsfehler installieren/aktualisieren.

Irgendwelche Ideen, was mir fehlt?

  • Ich denke, das hat sehr wenig mit WordPress selbst zu tun und SO ist ein viel besserer Ort, um danach zu fragen

    – Mark Kaplun

    21. September 2016 um 4:20 Uhr

  • @MarkKaplun laut die Hilfedateien, Serverkonfiguration für WordPress ist zum thema. Ich nehme an, Sie könnten auch argumentieren, dass dies ein generisches Serverkonfigurations- und Verwaltungsproblem ist, was würde nicht beim Thema sein.

    – GlückReis

    21. September 2016 um 5:19 Uhr

  • Ich hasse wirklich Leute, die vorgeben, Anwälte zu sein, die vor Gericht stehen. Nicht jeder Ort auf der Welt ist Schauplatz eines Fernsehdramas

    – Mark Kaplun

    21. September 2016 um 5:45 Uhr

  • @MarkKaplun Nun, ich denke, ich würde mich entschuldigen, wenn mein Kommentar Sie beleidigt hat. tbh Ich war mir nicht ganz sicher, ob meine Frage in diesem Forum angemessen ist, und da Sie andeuteten, dass dies nicht der Fall ist, suchte ich nur nach einer veröffentlichten Richtlinie als Referenz.

    – GlückReis

    21. September 2016 um 5:48 Uhr

  • Wenn andere Leute Hilfe zu dieser Frage anbieten möchten, tun Sie dies bitte. Ansonsten frage ich gerne woanders nach. Tatsächlich hatte ich auf Serverfault gefragt, aber ich habe dort nicht viel Hilfe bekommen.

    – GlückReis

    21. September 2016 um 5:50 Uhr

Benutzer-Avatar
Kabanus

Schauen Sie sich an: Was bedeutet mode_t 0644?

644 means:
 * (owning) User: read & write
 * Group: read
 * Other: read

CRUD ist ein Schreibbefehl, also dürfen Sie das nicht. Entweder Sie wechseln zu 664 oder verwenden Sie weiterhin sudo. Grundsätzlich wäre ohne sudo kein Schreibvorgang auf dem Dateisystem erlaubt, da Ihr Benutzer nicht der Besitzer ist (obwohl er in der Gruppe ist).

@fortuneRice, CentOS7 bietet standardmäßig aktiviertes Selinux, was oft die Ursache für viele schwer verständliche Dateiberechtigungsfehler ist.

Ich würde folgendes vorschlagen:

  1. Bearbeiten Sie /etc/sysconfig/selinux
  2. Ändern Sie SELINUX=permissive (oder was auch immer SELINUX derzeit in der Datei eingestellt ist) zu SELINUX=deaktiviert
  3. Starten Sie Ihren Server neu (nicht nur den Apache-Webserver, sondern die gesamte Maschine)

Das vollständige Deaktivieren von SELINUX ist keine gute Idee. Wenn dieses Verfahren funktioniert, sollten Sie SELINUX daher erneut aktivieren und seine Konfiguration korrigieren.

Die Konfiguration von SELINUX kann eine schwierige Aufgabe sein, daher schlage ich vor, dass Sie bei Google nachlesen, wie das geht 🙂

Benutzer-Avatar
Sukhjinder Singh

chown -R -f user:apache /path of the directory

  • Es wird bevorzugt, den Befehl zu erklären und wie er das Problem löst.

    – Tuschar

    27. Oktober 2016 um 5:29 Uhr


  • Sie sollten WordPress keine Erlaubnis erteilen. Platzieren Sie einfach den WordPress-Ordner auf dem Server und ändern Sie den Besitz auf den Benutzer (wie im Befehl geschrieben).

    – Sukhjinder Singh

    27. Oktober 2016 um 5:35 Uhr

  • Ok, bearbeiten Sie die Antwort und fügen Sie die Beschreibung in Antwort hinzu. Auf diese Weise können zukünftige Leser die Beschreibung in der Antwort selbst sehen.

    – Tuschar

    27. Oktober 2016 um 5:43 Uhr

Benutzer-Avatar
Oren Hahiashvili

Ich bin auch mit diesem Problem konfrontiert und habe dieses Problem gelöst, indem ich den PHP-Handler geändert habe.

Es ist wichtig, den PHP-Handler zu verwenden, der als Dateieigentümer ausgeführt wird.

Nachdem ich HTTP2 und noch ein paar Features auf dem Weg installiert habe, habe ich den PHP-Handler geändert.

Ich verwende WHM/CPanel auf meinem VPS und habe mein Problem folgendermaßen behoben:

  1. Unter WHM > Software > EasyApache 4 > Customize

    Suche nach: mod_suphp unter dem Apache Modules und vergewissern Sie sich, dass es aktiviert ist, und wenn Sie es gerade zur Installation aktiviert haben, folgen Sie Schritt zwei.

  2. Gehen Sie zum Review Registerkarte und klicken Sie auf die Provision Schaltfläche zum Speichern.

  3. Unter Whm > Software > MultiPHP Manager suchen PHP Handlers Tab.

  4. Wählen suphp als Handler für die aktuelle PHP-Version.

Das ist es. Es war der PHP-Handler.

Edit: Das merke ich suphp hatte einen Konflikt mit einem meiner Benutzer-Upload-Verzeichnisse, dass ich Bildern dynamisch ein Wasserzeichen hinzufüge. Es scheint die suphp Der Handler hatte die Erlaubnis zum Hochladen, zeigt aber die Bilder nicht. Ich habe auch versucht, die lsapi für den PHP-Handler, und es scheint mit den Dateiberechtigungen und dem Anhängen von Wasserzeichen für Bilder über die .htaccess-Datei korrekt zu funktionieren.

1382770cookie-checkWordPress-Dateiberechtigungen auf CentOS7 erfordern sudo

This website is using cookies to improve the user-friendliness. You agree by using the website further.

Privacy policy