Update - The following paths are not writable:

  • Betroffene Version
    WoltLab Suite 5.4

    Grüße,

    ich erhalte folgende Meldung:

    Fehlercode anzeigen
    Aufgerufene URL
    POST /acp/index.php?install-package/&t=7dc5560da25214f305ef55cf079c31305726989452627560d92cebd45ba93740-Wyp9HXb5pOcYPvL7xpRFaA==
    Referrer
    https://qbass17.cc/acp/index.php?package-update/
    WoltLab Suite
    5.4.1
    PHP
    7.4.3
    Fehlermeldung
    The following paths are not writable: templates/compiled/4_notificationList.meta.php,templates/compiled/4_eventPreview.meta.php,templates/compiled/2_boxSidebarCommentList.meta.php,templates/compiled/0_threadAdd.meta.php,templates/compiled/4_userProfileLikeItem.meta.php,templates/compiled/4_unreadEventList.meta.php,templates/compiled/0_sitemapEntry.meta.php,templates/compiled/0_board.meta.php,templates/compiled/4_messageQuoteList.meta.php,templates/compiled/4_birthdaySearchableOptionType.meta.php,…
    Art
    RuntimeException
    Datei (Zeile)
    /home/users/qbass17/www/qbass17/lib/system/WCF.class.php (1340)
    Stacktrace
    1. /home/users/qbass17/www/qbass17/lib/acp/action/InstallPackageAction.class.php (171): wcf\system\WCF::checkWritability(…)
    2. /home/users/qbass17/www/qbass17/lib/action/AbstractDialogAction.class.php (73): wcf\acp\action\InstallPackageAction->stepPrepare(…)
    3. /home/users/qbass17/www/qbass17/lib/action/AbstractAction.class.php (53): wcf\action\AbstractDialogAction->execute(…)
    4. /home/users/qbass17/www/qbass17/lib/system/request/Request.class.php (89): wcf\action\AbstractAction->__run(…)
    5. /home/users/qbass17/www/qbass17/lib/system/request/RequestHandler.class.php (119): wcf\system\request\Request->execute(…)
    6. /home/users/qbass17/www/qbass17/acp/index.php (11): wcf\system\request\RequestHandler->handle(…)

    Um welchen Order/Dateien handelt es sich, auf was muss das stehen?
    Unter Forum > Templates gibt es kein compiled
    Direkt unter Templates gibt es compiled der Ordner steht auf 777 und die Dateien auf 644

  • Ok, wurde verschoben, aber keine Hilfe?Ich würde gerne updaten, aber irgendwas stimmt hier nicht.

    Ich habe zuvor nichts geändert an Ordner und Dateien. Ich stelle das alles mal auf 777 bis mir eventuell jemand sagen kann, wie das überhaupt richtig aussehen muss. Das Update auf die frische 5.4 war kein Problem gewesen, auf die 5.4.2 ergab es diesen Fehler.

    • Offizieller Beitrag

    Hallo,

    Fragen zu den individuellen Berechtigungen können wir leider nicht pauschal beantworten. Wir nutzen die Standardfunktionen von PHP zur Ermittlung, ob Dateien beschreibbar sind oder nicht, PHP selbst bezieht diese Angaben selbst vom Betriebssystem. Und wenn PHP uns meldet, dass die Datei für PHP nicht beschreibbar ist, dann ist das auch so.

    Bitte beachte, dass 644 unzureichend sein kann, wenn der Besitzer der Dateien nicht identisch mit dem PHP-Prozess ist.

  • Grüße,

    es handelt sich hier doch um Standard Ordner und Dateien?

    Das Update von 5.3* auf 5.4 war problemlos, bis auf Kompatibliäten einzelner Plugins. Auch 5.4.1 war kein Pronlem.

    Nur auf das aktuelle 5.4.2 gab es das Problem. Ich hatte gedacht, dass man sagen kann, wie das zustande kommt?

    Manuell wurden die Dateien oder Ordner nicht angepasst bzw. verändert.

    • Offizieller Beitrag

    Hallo,

    das hat überhaupt nichts mit dem Update selbst zu tun, sondern mit dem Umstand, dass wir bei allen Updates des Core pauschal die Berechtigungen prüfen. Wenn sich zwischenzeitlich der Benutzer geändert hat, unter dem PHP ausgeführt wird, können Dateien mit falschen Berechtigungen erstellt werden. Diese sind dann zwar lesbar, aber eben nicht mehr veränderlich.

    Bitte korrigiere die Berechtigungen, das hat mit dem Update nichts zu tun.

  • Wenn PHP als z.B. www-data laueft und der Pfad /var/www ebenfalls von www-data ge-owned ist,

    reicht auf File-Ebene ein 640 und auf Folder ebene ein 750.

    sudo find /var/www/ -type d -exec chmod 750 {} + && sudo find /var/www/ -type f -exec chmod 640 {} +

    Med venlig hilsen / Regards,

    Alex

  • Ordner steht auf 777 und die Dateien auf 644

    Wenn PHP als z.B. www-data laueft und der Pfad /var/www ebenfalls von www-data ge-owned ist,

    reicht auf File-Ebene ein 640 und auf Folder ebene ein 750.


    sudo find /var/www/ -type d -exec chmod 750 {} + && sudo find /var/www/ -type f -exec chmod 640 {} +

    Komisch, dass war sogar höher eingestellt.. Übersteigt meinen Verstand..

    Danke

  • 777 ist grob fahrlaessig.

    Die erste Zahl ist Owner,

    Die zweite Zahl ist Group,

    Die dritte Zahl ist Public.

    Wenn du 777 gibts, kann jeder alles, ist nicht gut.

    --> https://chmod-calculator.com/

    Eventuell hilft dir die Website das besser zu verstehen.

    777 sollte man nie vergeben.

    Med venlig hilsen / Regards,

    Alex

  • Ja aber ich verstehe folgendes nicht

    Die Rechte waren höher eingestellt, aber es gab Probleme.

    Alexander sagt, dass 644 zu wenig sein kann.

    Jetzt bekomme ich Infos zu 750 und 640

    Das irritiert, als das es hilft. Wie ist denn die Rechtevergabe Standard. Das habe ich mehrmals erfragt, aber keine wirkliche Antwort bekommen.

    Mit 777 und 666 habe ich das Update durchführen können. Aber dennoch würde ich nun gerne wissen, wie die Standard-Vergabe aussieht und übernehme erst einmal deine Empfehlung.

    Danke dafür.

  • Und diese Aussage ist grober Unfug. Wie bereits erwähnt, kommt das auf den Server und dessen Konfiguration an.

    777 ist auf jedem Linux Server Read/Write fuer alle, das hat nichts mit dem Server oder deren Configuration zu tun sondern sind Linux Permissions...

    Frag doch mal in jedem Linux IRC oder Forum ob es so gut ist 777 auf Files/Folder zu geben, keiner wird sagen "klar mach mal. "

    Med venlig hilsen / Regards,

    Alex

  • 777 ist auf jedem Linux Server Read/Write fuer alle, das hat nichts mit dem Server oder deren Configuration zu tun sondern sind Linux Permissions...

    Frag doch mal in jedem Linux IRC oder Forum ob es so gut ist 777 auf Files/Folder zu geben, keiner wird sagen "klar mach mal. "

    Es gibt Fälle, wo es einen solchen Bedarf gibt. Sonst gäbe es diese Option erst gar nicht.

    „If you can only do one thing, hone it to perfection. Hone it to the utmost limit!“ – Zenitsu Agatsuma

  • 777 ist auf jedem Linux Server Read/Write fuer alle, das hat nichts mit dem Server oder deren Configuration zu tun sondern sind Linux Permissions...

    Frag doch mal in jedem Linux IRC oder Forum ob es so gut ist 777 auf Files/Folder zu geben, keiner wird sagen "klar mach mal. "

    *Lacht in SELinux*

  • Es gibt Fälle, wo es einen solchen Bedarf gibt. Sonst gäbe es diese Option erst gar nicht.

    Naja welchen Fall soll es da geben?

    Der einzige der mir einfallen wuerde ist, wenn du ein Script auf deiner Linux Kiste fuer alle Zugaenglich machen willst inkl. ausfuehrbar.

    Andernfalls macht 777 keinen Sinn. Schon gar nicht im Web-Ordner weil man damit potenziell Schad-Code via dem PHP-Socket ausfuehren kann wenn man weiß wie.

    Und klar der root Nutzer ans sich hat Zwangsweise ueberall volle Rechte, da ist es logisch das es 777 auch geben muss.

    Wenn man den Server aber richtig konfiguriert hat braucht es kein 777. Das ist sonst wie mit Kanonen auf Spazen schiessen.


    *Lacht in SELinux*

    Gut das ist ein Spezial-Fall.

    Med venlig hilsen / Regards,

    Alex

  • Die Sache ist eher die: Wenn bei einem Webprojekt die Berechtigungen in dieser Form relevant werden, hat man ein ganz anderes Problem. Denn dann ist da jemand auf dem Server, der böse Dinge beabsichtigt. Und wenn er schon auf dem Server ist, werden ihn diese Berechtigungen auch nicht mehr von irgendwas abhalten.

    Klar sollte man die Berechtigungen so gering wie möglich setzen, aber als „grob fahrlässig“ würde ich es nicht betrachten.

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!