Beiträge von Supporter

    Allerbesten Dank für Deine Hilfe!

    Aus reiner Noobigkeit hatte ich zunächst versucht, den Befehl in den Cronjob selbst zu integrieren, was natürlich nicht geklappt hat. Erst später habe ich dann entdeckt, wo ich bei Netcup zusätzliche Argumente zur Ausführung von Cronjobs beifügen kann.

    Ich habe dann noch etwas Housekeeping innerhalb der Nextcloud betreiben müssen (Logdateien löschen etc.), aber nun läuft sowohl der Cronjob als auch der Upload größerer Ordner wieder wie es soll.

    Du warst eine echte Unterstützung und ich wünsche Dir ein 2025 mit sauberem Code und ohne jeden Bug.

    Vielen Dank für Deinen Input!

    Ich bekomme dieselben Ausgaben wie Du, also

    Code
    memory_limit => 128M => 128M

    und nach Ausführung des zweiten Befehls

    Code
    memory_limit => 1024M => 1024M

    Wenn ich dann allerdings erneut abfrage, erhalte ich wieder:

    Code
    bash-5.1$ php -i | grep memory_limit
    memory_limit => 128M => 128M

    Im Control Panel sieht eigentlich alles gut aus, würde ich meinen:

    php_info.png


    Im Zweifelsfall mal beim Cronjob das gewünschte memory_limit mit angeben.

    Wie genau kann ich das tun?

    Hallo zusammen,

    wünsche allen, schöne Weihnachten gehabt zu haben! ;)

    Ich betreibe auf einem Webhosting 8000 SE zwei Nextcloud-Instanzen in der jeweils aktuellsten Version (derzeit 30.0.4). Natürlich beide mit geringer Last und nur jeweils zwei Benutzern, das Hosting ist logischerweise relativ limitiert.

    Auf einer Instanz habe ich seit einigen Tagen mir nicht recht erklärliche Probleme. Der eingerichtete Cronjob schlägt fehl und wirft die Meldung:

    PHP Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to allocate 24576 bytes) in /var/www/vhosts/hosting118930.a2fa9.netcup.net/nextcloud.$domain.de/lib/private/Blurhash/Listener/GenerateBlurhashMetadata.php on line 85

    Zusätzlich hängt sich der Nextcloud-Client regelmäßig auf, wenn ich Ordner mit (grob geschätzt) mehr als 80 Dateien in die Nextcloud schiebe und diese entsprechend hochgeladen werden müssten.

    Hier kommt es im Log zu Fehlermeldungen wie:

    Allowed memory size of 134217728 bytes exhausted (tried to allocate 76354224 bytes) at /var/www/vhosts/hosting118930.a2fa9.netcup.net/nextcloud.$domain/lib/private/Files/Storage/Local.php#296

    Bei Ordnern mit weniger Dateien klappt es nach wie vor zuverlässig und der Upload von großen Ordnern über die Weboberfläche der Nextcloud funktioniert auch. Weitere Fehler im Log lauten:

    DbalException An exception occurred while executing a query: SQLSTATE[40001]: Serialization failure: 1213 Deadlock found when trying to get lock; try restarting transaction

    Ich laufe also offenbar in Speicherlimits, verstehe aber leider nicht, an welcher Stelle genau. Es gab keine Konfigurationsänderung an dieser Instanz und die zweite Nextcloud läuft auf dem selben Hosting ja auch nach wie vor problemlos.

    Ich wäre daher sehr dankbar für jeden Tipp...

    Vielen Dank! Hmm, open_basedir steht überall auf DOCROOT, Fehlermeldungen tauchen aber bisher nicht auf, Ich gehe bei Berechtigungen prinzipiell gerne nach dem Muster vor "so viel wie nötig, aber so wenig wie möglich", daher würde ich es zunächst nicht anfassen.

    Bin mir aber tatsächlich auch nicht sicher, ob ich das Ganze konzeptionell überhaupt korrekt verstehe...

    Hallo zusammen,

    ich betreibe drei kleine Nextcloud-Instanzen in meinem Webhosting-Paket. In der Basis-Konfiguration werden die Logs der Nextclouds mit Meldungen zugespamt, dass kein Zugriff auf das "tmp"-Verzeichnis möglich sei. Man kann nun einen "tmp"-Ordner im Verzeichnis der jeweiligen Instanz anlegen, dies führt aber wiederum bei jedem Update zu einer Fehlermeldung. Für Nextcloud-Betreiber auf Webhostings ist dies glaube ich ein bekanntes Thema.

    In den PHP-Einstellungen für meine (Sub-)Domains kann ich ja den Wert für upload_tmp_dir anpassen - von "DOCROOT" auf "WEBSPACEROOT". Verstehe ich es richtig, dass wenn ich für alle Nextcloud-Instanzen "WEBSPACEROOT" einstelle, sie sich dann /tmp im Rootverzeichnis teilen? Sind durch diese gemeinsame Nutzung irgendwelche Nachteile oder Probleme zu erwarten?

    Danke für Eure fachkundige Einschätzung! :)

    Besten Dank für Euer Feedback und die Beteiligung am Thread! Grundsätzlich würde ich aber anregen wollen, dass es inhaltlich bei Beiträgen zur Hotline bzw. zum Support allgemein bleibt.

    Darüber hinaus bin ich gespannt, in wieweit sich die Situation in der Hotline zukünftig bessert, wobei es natürlich am besten wäre, sie gar nicht benötigen. :)

    Hallo zusammen,

    ich wollte mich mal kurz in Sachen Netcup-Hotline austauschen.

    Ich bin seit mehreren Jahren Kunde mit dem 8000er Webhosting, habe Netcup-Webhostings aber auch schon für eine zweistellige Zahl (kleiner) Kunden eingerichtet.

    Entgegen manch anderem Bericht hier habe ich nie das Gefühl gehabt, über Gebühr lange in der Warteschleife zu hängen, an dieser Stelle also alles prima. Alles bis 10 Minuten finde ich erträglich.

    Was aus meiner Sicht aber leider über die Jahre spürbar nachgelassen hat, ist die Qualität der Hotline. Ich habe es immer geschätzt, auf telefonischem Wege zu Lösungen zu kommen und - zumindest in zweiter Instanz - mit jemandem sprechen zu können, der technisch gut im Thema ist.

    Meine letzten drei Anrufe bei der Hotline (verteilt über das letzte halbe Jahr) hatten alle dasselbe Ergebnis: Ein kurzes Gespräch mit einem wenig motiviert wirkenden Mitarbeiter, der mich bittet, dass ich mein Anliegen bitte per Mail senden solle, damit es sich die "Fachabteilung" ansieht.

    Dabei hatte ich keinesfalls immer tiefgreifende Fragen, heute Morgen wollte ich z.B. nur wissen, ob der Netcup-Mailserver zickt, da ich ständig SMTP-Timeouts bekam. So etwas könnte/sollte auch der 1st-Level-Support wissen bzw. in Erfahrung bringen können, oder wie seht Ihr das?

    Wenn man die Kunden aus Kapazitätsgründen nicht in den 2nd-Level weiterleiten kann, wäre es doch zumindest kundenfreundlich, wenn der 1st-Level die Anfrage aufnimmt und intern weiterleitet, sodass der Kunde dann irgendwann eine Rückmeldung erhält und nicht selbst noch einmal tätig werden muss.

    Andernfalls wäre es nur konsequent, die Hotline abzuschalten und eben pauschal nur noch Support per Mail bzw. Formular anzubieten, oder?

    Nichtsdestotrotz gibt es ein dickes <3 für Netcup, da hier ansonsten aus meiner Sicht doch vieles ganz prima läuft, den Kunden viele Freiheiten eingeräumt werden, man technisch (in den meisten Bereichen) mit der Zeit geht und das Preis-Leistungsverhältnis gut ist.

    Daher darf die Moderation diesen Thread auch gerne als konstruktive Kritik verstehen und entsprechend weiterleiten, auf dass die Liebe noch viele Jahre heiß brennen möge. ;)

    Ok, prima. Aber Änderungen werden an dieser Stelle vom Server nur einmal pro Stunde eingelesen und umgesetzt, verstehe ich das richtig?

    Also im schlimmsten Fall 59 Minuten warten, bis die neuen Einstellungen greifen?

    Vielen Dank, sehr hilf- und lehrreich, was Ihr schreibt. Ich bin System- und Netzwerkadmin im Windows-Umfeld, daher ist hier viel Neuland für mich.

    In der phpversion.readme steht allerdings:

    The following short PHP version strings are available on the CLI:

    56

    70

    71

    72

    73

    74


    Bedeutet das, ich sollte in /conf/phpversion besser die 74 eintragen, da 81 gar nicht akzeptiert werden würde?

    Schon mal besten Dank für Eure schnellen Antworten, echt klasse!

    Der richtige Pfad zu occ sollte das Nextcloud-Wurzelverzeichnis sein.

    Paul: Ich kann Deine Kritik gut nachvollziehen. "Blind" tippe ich in sofern nichts ein, als dass ich vorher von allem Backups erstelle. Ich komme also zumindest zurück, wenn ich Mist baue. ;)

    Du hast aber in soweit Recht, als dass ich noch nicht wirklich verstehe, wann ein Befehl mit sudo ausgeführt werden muss und wann nicht - und warum in der Tat in sehr vielen HowTos Befehlen ein "sudo" vorangestellt ist, wenn es offenbar gar nicht benötigt wird.

    Wenn ich "php occ maintenance:mode --on" nutze, scheint es prinzipiell zu klappen. Allerdings erscheint: "You are currently running 7.3.33. Please update your PHP version.bash-5.0$"

    Das ist verwunderlich, denn auf der entsprechenden Subdomain ist PHP 8.1 eingestellt...

    Hallo Community,

    ich bin leider sehr unwissend auf der Linux-Kommandozeile. Was ich möchte: Einige SSH-Befehle gegen meine Nextcloud-Instanz abzusetzen, die auf einem Webhosting 8000 SE läuft.

    Das Login über Putty klappt, der Wechsel in das Installationsverzeichnis ebenfalls.

    "sudo -u www-data php occ maintenance:mode --on" führt aber direkt zu "sudo: command not found".

    Wo liegt mein Fehler?