hudi30hudi30 MemberComments: 22 Received thanks: 2 Member since: January 2017 edited August 2020

Hallo zusammen,

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

Answers

  • _MikeB_MikeB MemberComments: 109 Received thanks: 11 Member since: August 2017

    Hi.

    Bist du hier weitergekommen? Ich habe aktuell das gleiche Problem bei einem Kundenprojekt. Vermute es liegt ein Rechteproblem vor...

     

    Gruß Mike

  • hudi30hudi30 MemberComments: 22 Received thanks: 2 Member since: January 2017

    Hi.

    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!

  • Moritz NaczenskiMoritz Naczenski AdministratorsComments: 9918 Received thanks: 3008 Member since: September 2013

    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?

  • hudi30hudi30 MemberComments: 22 Received thanks: 2 Member since: January 2017

    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!)

  • lesting_lmclesting_lmc MemberComments: 2 Received thanks: 0 Member since: September 2020

    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.

  • Moritz NaczenskiMoritz Naczenski AdministratorsComments: 9918 Received thanks: 3008 Member since: September 2013

    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.

  • FreieBieneFreieBiene MemberComments: 6 Received thanks: 0 edited September 2020 Member since: September 2020

    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? 

  • Moritz NaczenskiMoritz Naczenski AdministratorsComments: 9918 Received thanks: 3008 Member since: September 2013

    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. 

  • FreieBieneFreieBiene MemberComments: 6 Received thanks: 0 Member since: September 2020

    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

  • Moritz NaczenskiMoritz Naczenski AdministratorsComments: 9918 Received thanks: 3008 Member since: September 2013

    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.

  • FreieBieneFreieBiene MemberComments: 6 Received thanks: 0 edited September 2020 Member since: September 2020

    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...

  • Moritz NaczenskiMoritz Naczenski AdministratorsComments: 9918 Received thanks: 3008 Member since: September 2013

    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. 

  • FreieBieneFreieBiene MemberComments: 6 Received thanks: 0 Member since: September 2020

    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! 

  • hudi30hudi30 MemberComments: 22 Received thanks: 2 Member since: January 2017

    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! 
    Thanked by 1FreieBiene
  • hudi30hudi30 MemberComments: 22 Received thanks: 2 Member since: January 2017

    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!  

  • FreieBieneFreieBiene MemberComments: 6 Received thanks: 0 Member since: September 2020

    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...

     

    LG

  • Moritz NaczenskiMoritz Naczenski AdministratorsComments: 9918 Received thanks: 3008 Member since: September 2013
    • 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.

    Was ist denn in dem genannten Order drin?

  • FreieBieneFreieBiene MemberComments: 6 Received thanks: 0 Member since: September 2020
    • 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.

    Was ist denn in dem genannten Order drin?

    Bei mir sind 4 Datein drin: https://prnt.sc/ufjwsh

  • joker464joker464 MemberComments: 23 Received thanks: 0 Member since: June 2020

    Hallo zusammen,

    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

  • hudi30hudi30 MemberComments: 22 Received thanks: 2 Member since: January 2017

    Ich habe nach dem Problem eine totale Neuinstallation gemacht und hatte keine Fehler mehr. Jetzt nach 3 Monaten tritt das selbe Problem schon wieder auf und verändert hat sich nicht! 
     

    Das Verhalten scheint mir echt nicht normal zu sein! 

  • bilobabiloba MemberComments: 14 Received thanks: 0 Member since: February 2018

    Wir haben das Verhalten auch schon beobachtet. Der Fehler tritt auch auf wenn ich über die Console

    rm -R prod_*

    ausführe. Wir haben die Worker von Shopware auf CLI umgestellt. Ich vermute es liegt daran. Die Rechte des Workers passen aber.

  • hudi30hudi30 MemberComments: 22 Received thanks: 2 Member since: January 2017

    Hallo zusammen,

    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


     

    Mir ist mittlerweile aufgefallen das Shopware das Verzeichnis ( var/cache/prod_.......) beim Auftreten des der Fehlers das Verzeichnis wohl nicht Löschen / Lesen kann und erstellt im gleichem Atemzug ein Neues Verzeichnis (prod_......) was Wahrscheinlich zu diesem Problem führen muss!
    Zu diesem Zeitpunkt lässt sich einer der Ordner nur mit viel mühe aus dem Verzeichnis löschen!

    @Moritz Naczenski kennst du evtl. der Grund warum Shopware plötzlich ein neues prod_...... im cache Verzeichnis erstellt?

Sign In or Register to comment.