Seit dem Release von Nextcloud 21.0.0 gab es vermehrt Meldungen darüber, dass der Cron sowie occ-Befehle nicht mehr ausgeführt werden können. Diese Probleme waren ausnahmsweise nicht auf Synology DiskStations bzw. DSM beschränkt. Seit dem Release 21.0.2 ist der Fehler bei einigen Usern wieder verschwunden, bei anderen hält er sich aber weiter. Mit 21.0.3 hat es einige Änderungen gegeben, die eigentlich für Nextcloud 22 gedacht waren, still und heimlich aber auch für 21 nachgezogen wurden.
Der Fehler
Lässt man den Nextcloud-Cron über den Cron des Servers – im Falle der DisksStation ist das der Aufgabenplaner – ausführen, wird dieser nicht mehr ausgeführt. Fehlermeldung erhält man (zumindest ab 21.0.3) keine mehr der Aufruf der cron.php funktioniert ja, allerdings tut diese nicht was sie tun soll. Einige User haben bereits herausgefunden, dass der Cron wieder funktioniert, wenn man die Zeile memcache.local aus der Nextcloud-Config entfernt.
Die Ursache
Standardmäßig ist das PHP-Caching (APCu) auf der Kommandozeile deaktiviert. Wenn ihr meine Artikel gelesen habt, erinnert ihr euch vielleicht daran, dass wir im PHP-Profil für Nextcloud das PHP-Caching aktiviert haben. Da das fehlende Caching in einigen Fällen Probleme mit dem Cron von Nextcloud macht, hat man beschlossen den Cron einfach nicht auszuführen wenn APCu deaktiviert ist. Sieht man in die Nextcloud-Doku steht da plötzlich:
“APCu is disabled by default on CLI which could cause issues with nextcloud’s cron jobs. Please make sure you set the apc.enable_cli to 1 on your php.ini config file or append --define apc.enable_cli=1 to the cron job call.”
Die Lösung
Für Synology DiskStations stellt sich jetzt wieder die Frage, wo ist denn der richtige Ort für die Änderungen. Im PHP-Profil findet sich zwar die Variable apc.enable_cli. Die auf 1 zu setzen löst das Problem aber nicht. Das PHP-Profil gilt ja nur für den Webserver und dort funktioniert APCu ja. Wir wollen aber APCu auf der Kommandozeile.
Um das Problem zu beheben legt ihr über z.B. PuTTY die Datei /usr/local/etc/phpXX/cli/conf.d/user_settings.ini an und fügt dort folgenden Inhalt ein:
extension = apcu.so [apc] apc.shm_size = 512M apc.enable_cli = 1
Speichert und schließt die Datei. Jetzt müsst ihr noch die Rechte anpassen und der Cron lässt sich wieder korrekt ausführen:
chmod -R 644 /usr/local/etc/phpXX/cli/conf.d/user_settings.ini
Vielen Dank an alle aus dem deutschen Synology Forum die ebenfalls die letzten Tage nach einer Lösung gesucht haben und vorallem an diejenigen die die Lösung zusammengetragen haben.
Möchtet Ihr noch detailliertere Schritt-Für-Schritt-Anleitungen für euer Synology NAS, mit viel mehr Hintergrundinformationen, Tipps und Tricks? Dann holt euch mein Wissen als als umfassendes Praxis-Handbuch. Mehr Infos findet ihr in keinem Buch zu Synology und alles in der von mir gewohnten Qualität.
Die dritte Auflage enthält Aktualisierungen zu DSM 7.1 und den Updates von WebStation, Surveillance Station und Synology Photos.
Das Buch direkt beim Verlag
Das Buch auf Amazon
Hallo zusammen,
habe zwar NC 24.x, aber auf meiner Synology mit PHP80 hat es auch den Memory-Fehler gegeben. Eintrag wie oben in die ../php80/cli/conf.d/user_settings.ini hat nix geholfen; witzigerweise ergibt “php80 -m” bei untersch. Benutzern untersch. Ergebnisse; ausgerechnet mit “sudo -u http php80-m” wird apcu.so NICHT aufgelistet, bei “sudo php80-m” schon.
Abhilfe: sudo “chmod -R 744 user_settings.ini” – jetzt bekomme ich auch bei “sudo -u http php80 -m” die Extension apcu.so aufgelistet!
Danke, das hat mir sehr geholfen!!!
Mir auch! Wie so oft: kleine Ursache, große Wirkung. Die Berichtigung der Berechtigung hat unserer Installation ENDLICH den PHP-Cache-Fehler augetrieben. Übrigens reicht 644 (es braucht ja keine Ausführungsrechte).
Tausend Dank!
Hallo Andreas, liebe Mitlesende,
ich war schon ganz hippelig, also ich über diese coole Seite gestolpert bin, weil ich schon so viel ohne Erfolg ausprobiert hatte: Aber ich krieg’s nicht hin 🤬 Wo klemmt es bloß?
Ich habe die von Dir oben beschriebene Datei erstellt unter
/usr/local/etc/php74/cli/conf.d/user_settings.ini
und aus lauter Verzweiflung auch noch unter
/volume1/@appstore/PHP7.4/usr/local/etc/php74/cli/conf.d/user_settings.ini
Jeweils Lese-/Schreibrechte für “root”
Aufruf des Nextcloud-Cron-Jobs per DSM-Aufgabenplaner (alle 5 Minuten):
sudo -u http php74 -f /volume1/web/nextcloud/cron.php -d apc.enable_cli=1
PHP-Memory Cache aktiviert, auch “*_cli” auf “1” gesetzt – Trotzdem: Der Cron-Job läuft nur bei auskommentierter Zeile
‘memcache.local’ => ‘\\OC\\Memcache\\APCu’,
in
/volume1/web/nextcloud/config/config.php
Mir gehen die Ideen aus. Habt Ihr noch welche?
Grüße
Olaf
Environment: DS 415+ oder auch RS 820+, DSM 7.1, Nexctloud 24.0.1, PHP 7.4
Ein kleiner Nachtrag:
Zu jedem in der Web Station-App erzeugten PHP-Profil gibt es ein Unterverzeichnis in
/var/packages/WebStation/etc/php_profile/
bzw. , da etc -> /volume1/@appconf/WebStation
/volume1/@appconf/WebStation/php_profile/
Diese Unterverzeichnisse sind mit wenig aussagekräftigen UUID benannt, darin finden sich jedoch user_settings.ini-Dateien, in denen vergleichbare Eintrage zu o. g. Parametern zu finden sind. Ein vollständiger Pfad wäre z. B.:
/var/packages/WebStation/etc/php_profile/irgendeine-uuid-abcd-1234-abcdefgh/conf.d/user_settings.ini
und die korrespondierenden Einträge, die hier allein durch die Anpassung der Paramter in der GUI entstanden sind, wären:
sh-4.4# vi user_settings.ini
zend_extension = opcache.so
extension = apcu.so
extension = bcmath.so
extension = bz2.so
extension = calendar.so
extension = curl.so
extension = exif.so
extension = http://ftp.so
extension = gd.so
extension = gettext.so
extension = gmp.so
extension = iconv.so
extension = imagick.so
extension = intl.so
extension = ldap.so
extension = mailparse.so
extension = mysqli.so
extension = openssl.so
extension = pdo_mysql.so
extension = posix.so
extension = soap.so
extension = sockets.so
extension = sodium.so
extension = xmlrpc.so
extension = zip.so
extension = zlib.so
display_errors = Off
open_basedir =
apc.enable_cli = 1
apc.shm_size = 512M
memory_limit = 512M
opcache.enable_cli = 1
opcache.interned_strings_buffer = 64
opcache.max_accelerated_files = 32531
opcache.memory_consumption = 512
opcache.revalidate_freq = 60
post_max_size = 128M
sys_temp_dir = /var/services/tmp
upload_max_filesize = 128M
Hi Olaf. Habe exakt das selbe Problem. Der beschriebene Guide bewirkt leider gar nix.
Hast du inzwischen eine Lösung gefunden?
Vielen dank!
Wer hätte gedacht das die Settings nicht für die Komandozeile gelten.
Es funktioniert wieder
Guten Abend Andreas,
hast du es schon mit NC 22.2 auf der Syno unter DSM 7 versucht?
Hallo Hans,
Ja, läuft bei mir schon, alles ohne Probleme.
Grüße
Andreas
Hier rennt es auch, Sodium musste ich bei php nachinstallieren.
jetzt moniert er noch drei Dateien:
– core
– EXTRA_FILE
– ocm-provider/config/config.sample.php
– ocm-provider/config/.htaccess
– ocm-provider/config/config.php
Kann ich die einfach weg löschen? Ich finde nix wofür ich die brauchen täte, aber eventuell verstehe ich auch mal wiedder die Fehlermeldung nicht, die haben die Integritätsprüfung nicht bestanden, nur die sind ja mit dem Download mit gekommen….
Hallo Hans,
Schau mal mit Putty in die Dateien rein. Im Ordner OCM hab ich nur die Datei index.php. Demnach könntest du die Dateien löschen.
Aber das sind die Dateien die eigentlich in /config drinnen sind. Schaut fast so aus als hätte eventuell das Backup die da falsch hinkopiert.
Kontrollier mal was da drinnen ist und ob in deiner neuen config.php eh alle Angaben korrekt sind.
Grüße
Andreas
Gerade geschaut, das sind Orginal die Dateien wie sie bei mir idcentisch im Config stehen, warum die da doppelt sind, komisch, ich nehme die gleich mal weg, aber wie die dahin gekommen sind würde mich interessieren.
So, gelöscht und rennt einwandfrei, Fehler nicht nachvollziebar, nach neuem Update sind die Dateien nicht da. nur noch den Cron zum laufen bringen, dazu die Frage, die leere Zeile, ist die Absicht in deinem Script oben?
Grüße Hans
Jein, die Zeile muss nicht sein, es ist einfach üblich in der Konfigdatei eine Leerzeile zwischen den Blöcken zu lassen.
Die erste Zeile gehört zum allgemeinen Block, dann kommt der Block der für die APC-Konfig verantwortlich ist.
Eine etwas umfangreichere Konfig könnte so aussehen:
extension=ex1extension=ex2
extension=ex3
[ex1]
variable=wert
variable=wert
[ex2]
variable=wert
[ex3]
variable=wert
variable=wert
variable=wert
Guten Morgen Andreas,
läuft, ich hatte deine Datei bei php74 wie beschrieben untergebracht, der Cronscript pointet bei mir aber noch auf php73 seit die datei da ist läuft es.Ich habe die da einfach hin kopiert oder ist es besser die beiden scripte auf php74 zu ändern?
Schönen Tag
Hans
Hallo,
Für Nextcloud wird PHP74 empfohlen, du kannst die Scripte natürlich auf PHP73 belassen, wenn du damit keine Probleme hast. Wichtig ist nur, dass der Speicherort und der Aufruf zusammenpassen. Also wenn du das obige Script unter php73 speicherst, musst du auch den Cron mit 7.3 aufrufen.
Grüße
Andreas
Die NC läuft auf php 7.4, die Cronscripte hatte ich nur nie angepasst
Ich bin ein Neuling in dem Bereich und weiß leider nicht, wie man die Datei anlegen kann und wie man diese dann speichert. Kann mir da jemand die passenden Befehle nennen? 🙂
Hallo Pierre,
Du musst dich mit PuTTY mit deiner DS verbinden. Dort steht dir VIM als Editor zur Verfügung.
Mit “vi /pfad/zur/datei/dateiname” öffnest du die Datei im Editor bzw legst sie auch gleich an wenn sie noch nicht existiert.
Mit “a” startest du den Schreibmodus, mit ESC beendest du ihn wieder. Danach tippst du “:x” und drückst ENTER, damit wird die Datei gespeichert und geschlossen.
Vim ist leider nicht der komfortabelste Editor. im Internet findest du aber einige Anleitungen.
Grüße
Andreas
Lange gesucht, bei dir die Lösung gefunden. Danke
Danke! Ich war schon fast am Verzweifeln. Funktioniert perfekt