Wenn ich ein Plugin aktiviere erscheint folgende Meldung.
Das Plugin konnte aufgrund der Fehlermeldung „Failed to remove directory „/var/cache/prod_h0d22ec9bb53e798b6ac9a9c72e8315a5/pools/fsk4t03muS/S“: rmdir(/var/cache/prod_h0d22ec9bb53e798b6ac9a9c72e8315a5/pools/fsk4t03muS/S): Directory not empty.“ nicht aktiviert werden
Wenn ich es deaktiviere
Das Plugin konnte aufgrund der Fehlermeldung „Failed to remove directory „/var/cache/prod_he9541c7b9f0627ef98026754bf7478b1/pools/tYmGtB1dIi/1“: rmdir(/var/cache/prod_he9541c7b9f0627ef98026754bf7478b1/pools/tYmGtB1dIi/1): Directory not empty.“ nicht deaktiviert werden
Hat das nicht etwas mit den Schreibrechten zu tun?
Der Ordner /var/cache/ hat die rechten Lesen und Schreiben.
Das Plugin ist mit der SW6 Version Kompatibel.
Wenn ich die Seite Einstellungen => Plugins verlasse und Sie dann wieder aufrufe wir der Plugin Status richtig angezeigt. Das Plugin scheint auch zu Funktionieren.
Weiss evtl. jemand wie man das machen müsste was die Fehlermeldung nicht mehr erscheint?
Nachtrag: Die Fehlermeldung kommt bei jedem Plugin
Bist du hier weitergekommen? Ich habe aktuell das gleiche Problem bei einem Kundenprojekt. Vermute es liegt ein Rechteproblem vor…
Gruß Mike
Hallo Mike, ja es ist zum …
Ich konnte das Problem nicht beheben.
Der misst muss durch ein Update passiert sein! (Irgendwo ab 6.3)
(Da wir einen eigenen Webserver haben, konnten wir die Ordner Schreibrechte etc. ohne probleme überprüfen. Jedoch ohne Erfolg!)
Hatte die Cache Ordner von einer Neuinstallation überschrieben und das brachte auch kein Erfolg somit muss der Fehler wohl von der DB stammen!
Mir ist aufgefallen das ein Update Shop Abweichungen hat gegenüber einer Neuinstallation!
(Da gab es wohl mehr als nur ein DB Problem!)
Ich bin nun wieder dran einen neuen Shop von Grund auf aufzubauen. (6.2.3) und die bereits über 500 Artikel kann ich in den Wind schmeissen da ich die nicht mal Portieren konnte!
Schade was so viele Arbeitsstunden einfach so in Rauch auf ging!
Also das wird an den Schreib- und Leserechten liegen. Wer ist denn der Besitzer des Plugin Ordners und ist dieser auch derjenige der den PHP Prozess ausführt?
Also das wird an den Schreib- und Leserechten liegen. Wer ist denn der Besitzer des Plugin Ordners und ist dieser auch derjenige der den PHP Prozess ausführt?
Bei uns hat die Bestehende sowie die Neuinstallation von SW6 dieselben Schreib und Leserechte.
Wir hatten zum Test bereits schon die Aktuellsten Updates in der Neuinstallation eingespielt und es schien alles zu funktionieren.
Denke wir haben schon jedes erdenkliche Szenario durchgespielt in der Hoffnung die alte SW6 Installation zu retten jedoch ohne Erfolg!
(Ich bin eigentlich immer noch von SW6 überzeugt leider, ist es sehr nervend wenn etliche Arbeitsstunden einfach so dahin sind!)
Ich hänge mich hier auch einmal dran, da ich anscheinend ein ähnliches Problem habe. Das aktivieren und deaktiveren von Plugins funktioniert nicht mehr, ebenso wie das Update. Es ist mir nicht ganz ersichtlich, welche Rechte wo liegen sollen. Die Ursprungsinstallation wurde via Composer durchgeführt. Falls jemand einen Tipp oder eine Lösung hat, würde ich mich freuen.
Du müsstest mal schauen, ob es die gleiche Fehlermeldung wie hier im Thread ist oder eine andere. Die Ursache muss ja nicht zwangswiese die gleiche sein und ich denke es bringt nichts, wenn du irgendeine Lösung ausprobierst, ohne zu wissen ob die Ursache die gleiche ist.
Am besten mal die Browser-Konsole öffnen und dort die API Request anschauen und die Fehlermeldung auslesen.
Du müsstest mal schauen, ob es die gleiche Fehlermeldung wie hier im Thread ist oder eine andere. Die Ursache muss ja nicht zwangswiese die gleiche sein und ich denke es bringt nichts, wenn du irgendeine Lösung ausprobierst, ohne zu wissen ob die Ursache die gleiche ist.
Am besten mal die Browser-Konsole öffnen und dort die API Request anschauen und die Fehlermeldung auslesen.
Hallo, seit dem letzten Shopware Update den gleichen Fehler (Screenshot by Lightshot) (Plugin lässt sich installieren, beim aktivieren (bei jeden Plugin) kommt jedoch dieser Fehler - gibt es schon einen fix?
Du müsstest mal schauen, ob es die gleiche Fehlermeldung wie hier im Thread ist oder eine andere. Die Ursache muss ja nicht zwangswiese die gleiche sein und ich denke es bringt nichts, wenn du irgendeine Lösung ausprobierst, ohne zu wissen ob die Ursache die gleiche ist.
Am besten mal die Browser-Konsole öffnen und dort die API Request anschauen und die Fehlermeldung auslesen.
Hallo, seit dem letzten Shopware Update den gleichen Fehler (https://prnt.sc/ufig3y) (Plugin lässt sich installieren, beim aktivieren (bei jeden Plugin) kommt jedoch dieser Fehler - gibt es schon einen fix?
Da würde ich zunächst die Schreib- und Leserechte auf dem Server prüfen. Die können sich natürlich auch mit einem Update ändern, je nachdem wie das Update auch durchgeführt wird. Am besten mal prüfen wer der Besitzer des genannten Ordners ist und diesen Rekursiv auf den Besitzer des PHP-Prozesses ändern au fdem Server.
Du müsstest mal schauen, ob es die gleiche Fehlermeldung wie hier im Thread ist oder eine andere. Die Ursache muss ja nicht zwangswiese die gleiche sein und ich denke es bringt nichts, wenn du irgendeine Lösung ausprobierst, ohne zu wissen ob die Ursache die gleiche ist.
Am besten mal die Browser-Konsole öffnen und dort die API Request anschauen und die Fehlermeldung auslesen.
Hallo, seit dem letzten Shopware Update den gleichen Fehler (https://prnt.sc/ufig3y) (Plugin lässt sich installieren, beim aktivieren (bei jeden Plugin) kommt jedoch dieser Fehler - gibt es schon einen fix?
Da würde ich zunächst die Schreib- und Leserechte auf dem Server prüfen. Die können sich natürlich auch mit einem Update ändern, je nachdem wie das Update auch durchgeführt wird. Am besten mal prüfen wer der Besitzer des genannten Ordners ist und diesen Rekursiv auf den Besitzer des PHP-Prozesses ändern au fdem Server.
Danke, kurze Frage kann ich die Rechte komplett auf 0777 änderns? - also alle rechte - oder gibt es da Probleme? LG
Das würde ich nicht machen - bei dem Plugin-Ordner kannst du das mal probieren, weil es da nicht so wichtig ist. Für alle Dateien solltest du das nicht machen.
Das würde ich nicht machen - bei dem Plugin-Ordner kannst du das mal probieren, weil es da nicht so wichtig ist. Für alle Dateien solltest du das nicht machen.
Okay aber in der Fehlermeldung, die ich erhalte (Screenshot by Lightshot) wäre es ja der /var/ cache / Ordner, der die Rechte erhalten müsste, richtig? (sorry ich weis nicht wo ich genau bei welchem Ordner die Rechte setzen muss…
Das würde ich nicht machen - bei dem Plugin-Ordner kannst du das mal probieren, weil es da nicht so wichtig ist. Für alle Dateien solltest du das nicht machen.
Okay aber in der Fehlermeldung, die ich erhalte (https://prnt.sc/uf86o1) wäre es ja der /var/ cache / Ordner, der die Rechte erhalten müsste, richtig? (sorry ich weis nicht wo ich genau bei welchem Ordner die Rechte setzen muss…
Ja, genau.
Du kannst den Ordner auch mal komplett löschen und dann schauen, ob es danach funktioniert.
Das würde ich nicht machen - bei dem Plugin-Ordner kannst du das mal probieren, weil es da nicht so wichtig ist. Für alle Dateien solltest du das nicht machen.
Okay aber in der Fehlermeldung, die ich erhalte (https://prnt.sc/uf86o1) wäre es ja der /var/ cache / Ordner, der die Rechte erhalten müsste, richtig? (sorry ich weis nicht wo ich genau bei welchem Ordner die Rechte setzen muss…
Ja, genau.
Du kannst den Ordner auch mal komplett löschen und dann schauen, ob es danach funktioniert.
Okay, also wenn ich /var/cache/ mal alle Rechte (0777) gebe passiert nix? Genau so, wenn ich den CACHE Ordner mal lösch? Der erstellt sich wieder alleine?
Da würde ich zunächst die Schreib- und Leserechte auf dem Server prüfen. Die können sich natürlich auch mit einem Update ändern, je nachdem wie das Update auch durchgeführt wird. Am besten mal prüfen wer der Besitzer des genannten Ordners ist und diesen Rekursiv auf den Besitzer des PHP-Prozesses ändern au fdem Server.
Sowas sollte ja eigentlich nicht passieren wenn man das Update über das Backend einspielt!
Das würde ich nicht machen - bei dem Plugin-Ordner kannst du das mal probieren, weil es da nicht so wichtig ist. Für alle Dateien solltest du das nicht machen.
Okay aber in der Fehlermeldung, die ich erhalte (https://prnt.sc/uf86o1) wäre es ja der /var/ cache / Ordner, der die Rechte erhalten müsste, richtig? (sorry ich weis nicht wo ich genau bei welchem Ordner die Rechte setzen muss…
Ja, genau.
Du kannst den Ordner auch mal komplett löschen und dann schauen, ob es danach funktioniert.
Okay, also wenn ich /var/cache/ mal alle Rechte (0777) gebe passiert nix? Genau so, wenn ich den CACHE Ordner mal lösch? Der erstellt sich wieder alleine?
Liebe Grüße!
Das mit dem Kompletten löschen und mit den Schreibrechten hat bei mir nicht geholfen! Habe sogar sämtlichen Ordner die selben Schreibrechte gegeben die bei der Neuinstallation auch hier kein Erfolg!
Da würde ich zunächst die Schreib- und Leserechte auf dem Server prüfen. Die können sich natürlich auch mit einem Update ändern, je nachdem wie das Update auch durchgeführt wird. Am besten mal prüfen wer der Besitzer des genannten Ordners ist und diesen Rekursiv auf den Besitzer des PHP-Prozesses ändern au fdem Server.
Sowas sollte ja eigentlich nicht passieren wenn man das Update über das Backend einspielt!
Bin ich auch der Meinung. Habe es auch normal über die Admin Oberfläche installiert, da ich in der Oberfläche eine Meldung bekommen habe, es sei ein neues Update verfügbar. Danach war halt wie gesagt bei jedem Plugin das Problem. Ich denke noch sicherer als in der Admin Oberfläche kann man gar kein Update einspielen/installieren…
Sowas sollte ja eigentlich nicht passieren wenn man das Update über das Backend einspielt!
Habe auch nichts anderes behauptet - daher der Hinweis, dass es da natürlich drauf ankommt, wie man das Update einspielt. Bei manuellem Update können sich die Rechte ja sehr wohl ändern. Die Fehlermeldung deutet ja auf ein Problem mit dem Cache-Ordner hin.
Sowas sollte ja eigentlich nicht passieren wenn man das Update über das Backend einspielt!
Habe auch nichts anderes behauptet - daher der Hinweis, dass es da natürlich drauf ankommt, wie man das Update einspielt. Bei manuellem Update können sich die Rechte ja sehr wohl ändern. Die Fehlermeldung deutet ja auf ein Problem mit dem Cache-Ordner hin.
auch ich hänge mich da mal dran. Wir haben die gleichen Fehlersymtome und ähnliche Meldungen. Alle Updates wurden alle über die Weboberfläche eingespielt. Auch wurden die Berechtigungen bereits neu gesetzt (744 bzw. 644). Bringt alles bisher leider keine Besserung. Hat jemand noch eine andere Idee, oder einen anderen Vorschlag?
Grüße
Das Plugin konnte aufgrund der Fehlermeldung “Failed to remove directory “/var/cache/prod_hb68f0bd20077f26a11080340d11de791/pools/5BSJTzhz3d/K”: rmdir(/var/cache/prod_hb68f0bd20077f26a11080340d11de791/pools/5BSJTzhz3d/K): Directory not empty.” nicht deaktiviert werden
Das Plugin konnte aufgrund der Fehlermeldung “Failed to remove directory “/var/cache/prod_hfcf08b573f5d263ded37967d98138065/pools/QC08fCTWLK/A”: rmdir(/var/cache/prod_hfcf08b573f5d263ded37967d98138065/pools/QC08fCTWLK/A): Directory not empty.” nicht aktiviert werden