Das PHP-Paket ist zwar schnell auf einer Synology DiskStation installiert, die richtige Konfiguration kann aber etwas komplexer ausfallen. Leider verhält sich PHP auf einer DiskStation etwas anders als auf einem gewöhnlichen Unix/Linux-Server. Gerade das PHP CLI verhält sich nicht immer wie erwartet. Manche Anwendungen lassen sich in der Konsole mit PHP 7 nicht ausführen. In diesem Artikel erkläre ich, wie man diesen Fehler behebt und so z.B. die Nextcloud-Konsolenkommandos occ mit PHP 7 ausführen kann.
sudo -u http php72 occ help
PHP hat zwei Seiten, eine davon wird von Webserver (z.B. Apache) genutzt. Die andere Seite ist das CLI (Command Line Interface). Damit lassen sich PHP-Befehle und Scripte auf der Shell ausführen (z.B. über putty). Um PHP auf der Konsole auszuführen wird der Befehl php genutzt. Sind mehrere Versionen installiert, gibt es für jede Version einen eigenen Befehl (z.B. php56, php70). In der CLI-Version vom PHP-7.0-Paket sind nicht alle Extensions verfügbar (warum weiß wohl nur Synology selbst). Aus diesem Grund kommt es z.B. bei der Ausführung von sudo -u http php70 occ … zu einer Fehlermeldung. Da Nextcloud 13 angeblich der letzte Mayor-Release ist, der PHP 5.6 unterstützt, könnte das schon sehr bald wichtig werden.
Um PHP 7.0 richtig verwenden zu können, muss das richtige Profil angegeben werden.
- Zuerst brauchen wir den Namen vom richtigen Profil. Diese werden unter /var/packages/WebStation/etc/php_profile/ in einem Ordner pro Profil abgelegt. Der Name ist nicht sprechend, ihr müsst also auf eurer DiskStation selbst danach suchen. Solltet ihr mehrere Ordner (mindestens 2, wenn ihr PHP 5.6 und PHP 7.0 installiert habt/hattet) vorfinden, und nicht wissen, welche zu PHP 7 gehört müsst ihr euch den Inhalt etwas genauer ansehen. In jedem Ordner findet sich ein conf.d-Ordner und darin ist das Profil gespeichert. Geht zuerst sicher, dass das PHP 7-Profil einen Unterschied aufweist:
- Öffnet im DSM die WebStation und seht euch unter den PHP-Einstellungen die Profile an, sucht nach einem Unterschied (z.B. Extensions die in einem Profil aktiviert sind, im anderen nicht).
- Wenn ihr keine findet, aktiviert/deaktiviert eine Extension in einem der Profile.
- Öffnet jetzt die Profile (in /var/packages/WebStation/etc/php_profile/<Buchstabensalat>/conf.d/) mit vi oder nano und seht euch die aufgelisteten Extensions an. Dort findet ihr den Unterschied wieder und könnt somit die Profile zuordnen.
- Merkt euch den Namen für das PHP 7.0 Profil.
- Erstellt ein Script mit folgendem Inhalt:
#!/bin/bash PHP_INI_SCAN_DIR=.:/usr/local/etc/php70/:/var/packages/WebStation/etc/php_profile/<Buchstabensalat>/conf.d/ export PHP_INI_SCAN_DIR php70 $*
Statt <Buchstabensalat> setzt ihr den Namen eures PHP 7.0 Profils ein, den ihr oben ermittelt habt.
- Testet das Script in dem ihr in putty folgenden Befehl ausführt:
<pfad_zum_script>/<Scriptname>.sh -i
Diser Befehl ist nichts anderes als php(70) -i also das phpinfo()-Äquivalent über die CommandLine. Wenn ihr alles richtig gemacht habt, wird euch die PHP 7.0-Konfiguration laut eurem Profil ausgegeben. Relativ zu Beginn der Ausgabe sollte auch die PHP-Version (in unserem Fall 7.0) aufgelistet sein.
- Jetzt könnt ihr die OCC-Commands (oder alles anderen, dass PHP 7.0 und gewisse Module benötigt) mit PHP 7.0 nutzen. Anstatt
sudo -u http php56 occ ...
Nutzt ihr die modifizierte PHP 7.0 CLI, indem ihr php56 einfach ersetzt:
sudo -u http <pfad_zum_script>/<Scriptname>.sh occ ...
- Jetzt könnt ihr den Nextcloud-Cron auch mit PHP 7.0 laufen lassen. Geht dazu im DSM in den Aufgabenplaner und erstellt eine neue Aufgabe, als Typ nehmt eigenes Script und lasst die Aufgabe alle 15 Minuten ausführen. Als Befehl gebt ihr folgendes ein:
sudo -u http <PfadZumScript>/<Scriptname>.sh /var/services/web/nextcloud/cron.php
- Da es etwas umständlich ist, immer den ganzen Pfad zum Script anzugeben und man den Pfad auch schnell mal vergisst, wenn man nach ein paar Wochen oder Monaten wieder einmal ein Nextcloud-Update macht, kann man sich das Leben ein wenig einfacher machen. Und zwar mit einem Alias. Man kann für die CommandLine einen Alias festlegen, also eine Art Abkürzung, dahinter kann sich ein langer Pfad verstecken aber auch ein komplexer Befehl inklusive verketteter Commands und Parametern. Wir wollen aber nur einen kurzen Alias für den Pfad und den Scriptnamen.
Alias werden in der .bashrc_profile (zu finden in /etc.defaults/) angelegt. Öffnet die Datei mit einem Editor eures Vertrauens (via putty). Bei mir waren schon 2 Alias-Einträge vorhanden, ich habe den neuen einfach darunter hinzugefügt, ansonsten sollte es egal sein, wo der Eintrag eingefügt wird. Die Syntax sieht folgendermaßen aus:alias="Befehl" in unserem Fall: alias="Pfad/zum/Script.sh"
- Jetzt müsst ihr Putty neu starten/die Verbindung neu aufbauen und dannach könnt ihr mit php7cli -i testen ob der Alias funktioniert. Ihr könnt ihn jetzt für die Aufrufe von occ-Commands nutzen oder auch in den obigen Aufruf der Nextcloud-Crons.Leider sind Anpassungen in der bashrc_profile genauso persistent wie z.B. die Anpassung des Timeouts von nginx und Apache, nachdem ihr ein DSM-Update installiert habe sind sie weg. Das heißt, ihr müsst sie dann weider neu eintragen.
Warum Synology im PHP-7.0-Paket nicht alle Extensions für die CLI-Version unterstützt, kann ich nicht sagen. Aber mit etwas Nachbessern bekommt man auch das geregelt. Vielen Dank an Lux007 aus dem Synology-Forum für die Lösung.
Ähnliche Beiträge
Hallöchen
Erst einmal für die meist sehr guten Beiträge im Bereich Synology.
Das Problem welches ich hier beschildere kommt zwar in Nextcloud vor, muss jedoch durch PHP 7.4 gelöst werden.
Leider funktioniert genau dieses nicht. Aus diesem Grund die eventuell etwas umständliche Erläuterung!
Es geht um eine Synology DS1517+ mit dem Betriebssystem DSM 7.1-42661 Update4.
Auf dieser habe ich unter anderem vor längerer Zeit NextCloud in das web-Verzeichnis installiert (kein Docker oder virtuelle Maschine) und konfiguriert.
Angelegt wurde ein Virtueller Host mit HTTP-Backend-Server: Apache HTTP Server 2.4 und Skript-Sprache PHP 7.4.28 und als Datenbank nutze ich MariaDB Version 10.3.32.
Es lief bis dato alles Fehlerfrei und es gab auch keine Warneldungen.
Erst jetzt habe ich ebenfalls nach längerer Zeit NextCloud wieder aktualisiert auf die Version 24.0.4.
Damit beginn auch das Problem!
Nun erhalte ich folgende Sicherheits- & Einrichtungswarnungen
– Fehlender Index “fs_id_storage_size” in der Tabelle “oc_filecache”.
– Fehlender Index “fs_storage_path_prefix” in der Tabelle “oc_filecache”.
– Fehlender Index “properties_pathonly_index” in der Tabelle “oc_properties”.
– Fehlender Index “job_lastcheck_reserved” in der Tabelle “oc_jobs”.
– Fehlender Index “direct_edit_timestamp” in der Tabelle “oc_direct_edit”.
welche normalerweise mit ‘occ db:add-missing-indices’ behoben werden sollten.
Der Zugriff erfolgt per ssh und der weiteren Anmeldung über ‘sudo -i’.
Die NextCloud-Installation liegt im Pfad ‘/volume1/web/nextcloud’, in das ich vor Befehlseingabe hinein gehe.
Befehl: ‘sudo -u html php occ db:add-missing-indices’
Fehler: This version of Nextcloud requires at least PHP 7.4You are currently running 7.3.3. Please update your PHP version.
Synology verwendet als Standard wohl nur die Version PHP (CLI) 7.3.3
O.k: NextCloud 24.0.4 benötigt nun mindestens PHP 7.4
Befehl: ‘sudo -u html php74 occ db:add-missing-indices’
Fehler: An unhandled exception has been thrown:
OCP\HintException: [0]: Memcache \OC\Memcache\APCu not available for local cache (Is the matching PHP module installed and enabled?)
Ich habe etliche Varianten ausprobiert um das ‘Memcache’ – ‘APCu’ Problem zu lösen wie z.B.
– ‘apc.enable_cli = 1’ in php.ini
– ‘extension = apcu.so’ in conf.d -> xxx
– ‘memcache.local’ => ‘\OC\Memcache\APCu’
in den Verzeichnissen
– /usr/local/etc/php74
– /etc/php
– /volume1/web/nextcloud
und sicherlich einiges mehr.
‘PHP 7.4’ habe ich zwischen meinen Versuchen auch deinstalliert und wieder neu installiert.
Auch das nutzen von ‘PHP 8.0.17’ brachte keine Verbesserung.
Leider habe ich bisher nicht die richtige Stelle oder Datei gefunden um dieses Problem zu lösen.
Ich bin sehr dankbar über einen vernünftigen detaillierten Lösungsvorschlag.
Für meine geringe Linux-Kenntnisse bitte ich um Rücksicht.
Hallo Olaf,
Der User des Webservers heißt auf der DiskStation http und nicht html, kannst du mal prüfen ob du da auch den richtigen User verwendet hast?
Bzw. bezüglich APCu, hast du schon diesen Artikel gelesen: https://blog.viking-studios.net/nextcloud-21-und-synology-cron-wird-nicht-mehr-ausgefuehrt/
Grüße
Andreas
Danke! (hint zu: php 7.2 + occ)
Hallo,
falls jemand wie ich an sich selbst zweifelt, weil nach dem Upgrade auf PHP 7.2 keine Datenbankverbindung mehr hergestellt werden kann: In der Datei /usr/local/etc/php72/cli/php.ini muss der Wert “pdo_mysql.default_socket” auf “/run/mysqld/mysqld10.sock” angepasst werden, sonst geht gar nichts.
Besten Dank an den Autor für’s aktuell Halten deiner Posts, du bist mir immer wieder eine Lebensrettung! Vielleicht aber dieses kleine Detail mit aufnehmen, oder in einem größeren Post zur Umstellung auf PHP 7.2 erwähnen.
Hallo,
Von welcher Datenbankverbindung sprichst du? Ich bin bisher auf kein Problem gestoßen.
Da ich ein ähnliches Problem hatte nach dem letzten PHP 5.6 Update folgt hier mein Bericht.
Eine Webseite (also nicht unbedingt CLI) funktionierte per PHP 7.2 nicht mehr nach dem letzten Syno Update.
Die WebSeite benutzt PDO und wird per DNS (mysql:host=localhost;dbname=Name_der_DB) initialisiert.
Fehler war
SQLSTATE[HY000] [2002] No such file or directory
Über die Webstation habe ich mir die php.ini Datei von PHP 7.2 angeschaut.
Dort war unter dem Reiter namens Kern
Unter pdo_mysql.default_socket war der Wert
/tmp/mysqld.sock
drin.
Nachdem ich diesen nach Wert
/run/mysqld/mysqld.sock
geändert habe und die Einstellungen gespeichert hatte, wurde der Webserver neu gestartet und meine Webseite lief wieder OK.
Unter PHP 5.6 ist dieser Wert auch verkehrt gespeichert.
Also die PHP Version ist weniger wichtig, aber PHP PDO und Zugriff auf MySQL (MariaDB) über Socket lief nichts mehr. Scheinbar wurde die Datei namens mysqld.sock aus dem tmp Verzeichnis entfernt.
Super Beitrag!
Ich habe zwei Synology NAS, bei beiden gehen nun die OCC Kommandos, aber bei einem habe ich einen Effekt, der mich etwas ratlos macht. Scheinbar wird am Ende eines jeden OCC Kommandos ein “a” hinzugefügt. Ich weiß, das klingt verrückt, ist aber so. Wenn ich zum Beispiel “occ maintenance:mode –on” ausführe, bekomme ich die Ausgabe “The “–ona” option does not exist.”
Woher kommt das “a”??? Ich mache das gleiche auf beiden NAS, bei einem geht es, beim anderen dieser seltsame Effekt.
Hat jemand eine Lösung oder Idee?
Sehr seltsam, davon hab ich noch nie gehört, passiert das nur bei den OCC Befehlen oder auch bei anderen?
Hallo,
ich habe nach der Installation noch folgende Fehler:
Du verwendest derzeit PHP 7.0.30. Upgrade deine PHP-Version, um die Geschwindigkeits- und Sicherheitsupdates zu nutzen, welche von der PHP-Gruppe bereitgestellt werden, sobald diese Deine Distribution unterstützt.
Dieser Installation fehlen einige empfholene PHP-Module. Für bessere Leistung und bessere Kompatibilität wird dringend empfohlen, diese zu installieren.
imagick
Bei einigen Spalten in der Datenbank fehlt eine Konvertierung in big int. Aufgrund der Tatsache, dass das Ändern von Spaltentypen bei großen Tabellen einige Zeit dauern kann, wurden sie nicht automatisch geändert. Durch Ausführen von “occ db: convert-filecache-bigint” können diese ausstehenden Änderungen manuell übernommen werden. Diese Operation muss ausgeführt werden, während die Instanz offline ist. Weitere Einzelheiten finden Sie auf der zugehörigen Dokumentationsseite.
filecache.mtime
filecache.storage_mtime
Laut meiner Info ist PHP 7.0.30-0027 auf meiner DS installiert wie kann ich PHP 7.3 installieren.
Die anderen Fehler habe ich so nirgendwo gefunden. Vielleicht kann mir ja einer/eine helfen.
mfg
Alexander
Hallo,
Also was PHP 7.3 angeht, sind wir wohl der Gnade von Synology ausgeliefert, da brauchts ein neues Paket, leider dauert das bei Synology immer recht lange und nicht jede Version kommt als Paket.
Eventuell schaffts einer aus der Community.
Zu imagick auf der DiskStation habe ich bisher noch nichts gehört oder gelesen, sobald ich etwas mitbekomme werde ich euch hier natürlich auf dem Laufenden halten.
LG
Auch auf die Gefahr hin das die Frage etwas unverschämt ist 🙂
Ich habe gestern meine Synology Nextcloud auf 15 angehoben und bekomme jetzt folgende Warnungen:
Es gibt einige Warnungen bei Deiner Systemkonfiguration.
Du verwendest derzeit PHP 7.0.30. Upgrade deine PHP-Version, um die Geschwindigkeits- und Sicherheitsupdates zu nutzen, welche von der PHP-Gruppe bereitgestellt werden, sobald diese Deine Distribution unterstützt.
Dieser Installation fehlen einige empfholene PHP-Module. Für bessere Leistung und bessere Kompatibilität wird dringend empfohlen, diese zu installieren.
imagick
An der PHP Version können wir nichts ändern (Wird irgendwann von selbst kommen) aber evtl Haben Sie einen Tipp wie ich imagick als PHP Modul installiert kriege?
Ihre Blog Einträge sind wirklich klasse. Ohne sie hätte ich die Nextcloud wahrscheinlich niemals vernünftig ans Laufen gebracht!
VG
Michael Ludes
Hallo,
Mich würde auch interessieren wie ich Imagick installiert bekomme.
Gruß Tom
Hallo,
Ich bin derzeit noch auf 14 und hab auch bisher noch nichts zu imagick auf einer DiskStation gehört bzw. gelesen. Ich vermute hierzu wird PHP 7.3 benötigt, welches auch von Nextcloud empfohlen wird. Da ich nicht glaube dass Synology ein neues PHP Paket in nächster Zeit nachliefert, hoffe ich auf die Community.
Sollte ich etwas dazu hören, werde ich euch natürlich hier informieren.
LG
Vielen Dank für die ganze Arbeit! Ich bin gerade dabei, der Synology diesen Cronjob mit cron.php beizubringen. Ich mache das so:
Ich lege in Systemeinstellung – Aufgabenplaner eine “Geplante Aufgabe” – “Benutzerdefiniertes Skript” an. Benutzer ist “root”. Unter dem Tab “Zeitplan” trage ich ein: Datum: “Täglich”. Erste Ausführungszeit ist: “00”. Frequenz ist: “Alle 15 Minuten”. Letzte Ausführungszeit ist: “23:45”. Unter dem Tab “Aufgabeneinstellungen” kommt unter “Befehl ausführen – Benutzerdefiniertes Skript”:
curl –insecure https://127.0.0.1/cron.php
Das läuft jetzt alle 15 Minuten. Im Nextcloud Admin-Konto unter “Einstellungen – Grundeinstellungen – Hintergrund-Aufgaben” erscheint der grüne Punkt. Unter “Protokollierung” erscheinen keine Fehlermeldungen. Cron macht jetzt im Prinzip nichts anderes als irgendein fremder Server, wenn ich “Webcron” bei “Hintergrund-Aufgaben” angegeben hätte. Soweit so gut.
Aber: Wenn ich “curl –insecure https://127.0.0.1/cron.php” im Terminal als root eingebe, kommt die Meldung:
{“data”:{“message”:”Backgroundjobs are using system cron!”},”status”:”error”}
Kann man das ignorieren? Läuft das jetzt wirklich? Würde mich über eine Einschätzung freuen.
Nochmal Danke!
Uli
PS: Etwas kurios: In /etc/crontab macht der Synology-Aufgabenplaner aus der oben beschriebenen Aufgabe (also ein Skript als root alle 15 Minuten auszuführen) die folgende Zeile:
0,15,30,45 0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23 * * * root /usr/syno/bin/synoschedtask –run id=6
Normalerweise würde man das doch so machen:
*/15 * * * * root /usr/syno/bin/synoschedtask –run id=6
Oder wenigstens so:
0,15,30,45 * * * * root /usr/syno/bin/synoschedtask –run id=6
Hmm.
Vielen Dank für die ganze Arbeit! Ich bin gerade dabei, der Synology diesen Cronjob mit cron.php beizubringen. Ich mache das so:
Ich lege in Systemeinstellung – Aufgabenplaner eine “Geplante Aufgabe” – “Benutzerdefiniertes Skript” an. Benutzer ist “root”. Unter dem Tab “Zeitplan” trage ich ein: Datum: “Täglich”. Erste Ausführungszeit ist: “00”. Frequenz ist: “Alle 15 Minuten”. Letzte Ausführungszeit ist: “23:45”. Unter dem Tab “Aufgabeneinstellungen” kommt unter “Befehl ausführen – Benutzerdefiniertes Skript”:
curl –insecure https://127.0.0.1/cron.php
Das läuft jetzt alle 15 Minuten. Im Nextcloud Admin-Konto unter “Einstellungen – Grundeinstellungen – Hintergrund-Aufgaben” erscheint der grüne Punkt. Unter “Protokollierung” erscheinen keine Fehlermeldungen. Cron macht jetzt im Prinzip nichts anderes als irgendein fremder Server, wenn ich “Webcron” bei “Hintergrund-Aufgaben” angegeben hätte. Soweit so gut.
Aber: Wenn ich “curl –insecure https://127.0.0.1/cron.php” im Terminal als root eingebe, kommt die Meldung:
{“data”:{“message”:”Backgroundjobs are using system cron!”},”status”:”error”}
Kann man das ignorieren? Läuft das jetzt wirklich? Würde mich über eine Einschätzung freuen.
Nochmal Danke!
Uli
PS: Etwas kurios: In /etc/crontab macht der Synology-Aufgabenplaner aus der oben beschriebenen Aufgabe, ein Skript als root alle 15 Minuten auszuführen, die folgende Zeile:
0,15,30,45 0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23 * * * root /usr/syno/bin/synoschedtask –run id=6
Normalerweise würde man das doch so machen:
*/15 * * * * root /usr/syno/bin/synoschedtask –run id=6
Oder wenigstens so:
0,15,30,45 * * * * root /usr/syno/bin/synoschedtask –run id=6
Hmm.
Also wenn der Punkt grün ist, würd ich mal sagen der Job wird ausgeführt.
Leider arbeitet die DS oft nicht sehr sauber wenn Eingaben in der GUI in Text/Config-Form umgesetzt werden.
Warums im Terminal nicht geht, kann ich dir auch nicht ganz sagen. Eventuell liegts auch daran, dass über die Commandline etwas fehlt, das der Webserver aber hat. Eben wie oben beschrieben die PHP 7 Module.
Grüße
Andreas
Danke für die schnelle Antwort! Es scheint alles zu laufen. Ich habe übrigens meine Installationserfahrungen auch mal zusammengefasst, unter:
https://www.lazybrowndog.net/nextcloud-on-synology-ds/
Ich habe das in Form von Screenshots gemacht, die man als eine Art Diashow anzeigen kann. Vielleicht hilft es ja dem ein oder anderen zusätzlich.
Liebe Grüße
Sehr hilfreicher Beitrag – danke dafür!
Bei mir kam übrigens zunächst die folgende Fehlermeldung:
The posix extensions are required – see http://php.net/manual/en/book.posix.php
Ich musste im DSM dann noch das posix-Modul hinzufügen – danach klappte es. 🙂
Irgendwie will das bei mir nicht funktionieren.
Bei mir bleiben die Fehler von Nextcloud.
Fehlender Index “share_with_index” in der Tabelle “oc_share”.
Fehlender Index “parent_index” in der Tabelle “oc_share”.
Fehlender Index “fs_mtime” in der Tabelle “oc_filecache”
Habe den Befehl von Daniel say ausgeführt und bekomme folgende Ausgabe.
admin@DS1817:~$ sudo -u http /usr/local/bin/php70 -c /var/packages/WebStation/etc/php_profile//conf.d/user_settings.ini -f /volume1/web/nextcloudnew/occ db:add-missing-indices
An unhandled exception has been thrown:
OCP\AppFramework\QueryException: Could not resolve defaultTokenProvider! Class defaultTokenProvider does not exist in /volume1/web/nextcloudnew/lib/private/AppFramework/Utility/SimpleContainer.php:110
Stack trace:
#0 /volume1/web/nextcloudnew/lib/private/AppFramework/Utility/SimpleContainer.php(125): OC\AppFramework\Utility\SimpleContainer->resolve(‘defaultTokenPro…’)
#1 /volume1/web/nextcloudnew/lib/private/ServerContainer.php(132): OC\AppFramework\Utility\SimpleContainer->query(‘defaultTokenPro…’)
#2 /volume1/web/nextcloudnew/lib/private/AppFramework/Utility/SimpleContainer.php(81): OC\ServerContainer->query(‘defaultTokenPro…’)
#3 /volume1/web/nextcloudnew/lib/private/AppFramework/Utility/SimpleContainer.php(104): OC\AppFramework\Utility\SimpleContainer->buildClass(Object(ReflectionClass))
#4 /volume1/web/nextcloudnew/lib/private/AppFramework/Utility/SimpleContainer.php(125): OC\AppFramework\Utility\SimpleContainer->resolve(‘OC\\Authenticati…’)
#5 /volume1/web/nextcloudnew/lib/private/ServerContainer.php(132): OC\AppFramework\Utility\SimpleContainer->query(‘OC\\Authenticati…’)
#6 /volume1/web/nextcloudnew/lib/private/AppFramework/Utility/SimpleContainer.php(171): OC\ServerContainer->query(‘OC\\Authenticati…’)
#7 /volume1/web/nextcloudnew/3rdparty/pimple/pimple/src/Pimple/Container.php(114): OC\AppFramework\Utility\SimpleContainer->OC\AppFramework\Utility\{closure}(Object(OC\Server))
#8 /volume1/web/nextcloudnew/lib/private/AppFramework/Utility/SimpleContainer.php(123): Pimple\Container->offsetGet(‘OC\\Authenticati…’)
#9 /volume1/web/nextcloudnew/lib/private/ServerContainer.php(132): OC\AppFramework\Utility\SimpleContainer->query(‘OC\\Authenticati…’)
#10 /volume1/web/nextcloudnew/lib/private/Server.php(364): OC\ServerContainer->query(‘OC\\Authenticati…’)
#11 /volume1/web/nextcloudnew/3rdparty/pimple/pimple/src/Pimple/Container.php(118): OC\Server->OC\{closure}(Object(OC\Server))
#12 /volume1/web/nextcloudnew/lib/private/AppFramework/Utility/SimpleContainer.php(123): Pimple\Container->offsetGet(‘OCP\\IUserSessio…’)
#13 /volume1/web/nextcloudnew/lib/private/ServerContainer.php(132): OC\AppFramework\Utility\SimpleContainer->query(‘OCP\\IUserSessio…’)
#14 /volume1/web/nextcloudnew/lib/private/AppFramework/Utility/SimpleContainer.php(171): OC\ServerContainer->query(‘OCP\\IUserSessio…’)
#15 /volume1/web/nextcloudnew/3rdparty/pimple/pimple/src/Pimple/Container.php(114): OC\AppFramework\Utility\SimpleContainer->OC\AppFramework\Utility\{closure}(Object(OC\Server))
#16 /volume1/web/nextcloudnew/lib/private/AppFramework/Utility/SimpleContainer.php(123): Pimple\Container->offsetGet(‘UserSession’)
#17 /volume1/web/nextcloudnew/lib/private/ServerContainer.php(132): OC\AppFramework\Utility\SimpleContainer->query(‘UserSession’)
#18 /volume1/web/nextcloudnew/lib/private/Server.php(1408): OC\ServerContainer->query(‘UserSession’)
#19 /volume1/web/nextcloudnew/lib/private/Server.php(683): OC\Server->getUserSession()
#20 /volume1/web/nextcloudnew/3rdparty/pimple/pimple/src/Pimple/Container.php(118): OC\Server->OC\{closure}(Object(OC\Server))
#21 /volume1/web/nextcloudnew/lib/private/AppFramework/Utility/SimpleContainer.php(123): Pimple\Container->offsetGet(‘OC\\App\\AppManag…’)
#22 /volume1/web/nextcloudnew/lib/private/ServerContainer.php(132): OC\AppFramework\Utility\SimpleContainer->query(‘OC\\App\\AppManag…’)
#23 /volume1/web/nextcloudnew/lib/private/AppFramework/Utility/SimpleContainer.php(171): OC\ServerContainer->query(‘OC\\App\\AppManag…’)
#24 /volume1/web/nextcloudnew/3rdparty/pimple/pimple/src/Pimple/Container.php(114): OC\AppFramework\Utility\SimpleContainer->OC\AppFramework\Utility\{closure}(Object(OC\Server))
#25 /volume1/web/nextcloudnew/lib/private/AppFramework/Utility/SimpleContainer.php(123): Pimple\Container->offsetGet(‘AppManager’)
#26 /volume1/web/nextcloudnew/lib/private/ServerContainer.php(132): OC\AppFramework\Utility\SimpleContainer->query(‘AppManager’)
#27 /volume1/web/nextcloudnew/lib/private/Server.php(1703): OC\ServerContainer->query(‘AppManager’)
#28 /volume1/web/nextcloudnew/lib/private/legacy/app.php(342): OC\Server->getAppManager()
#29 /volume1/web/nextcloudnew/lib/private/legacy/app.php(113): OC_App::getEnabledApps()
#30 /volume1/web/nextcloudnew/lib/base.php(654): OC_App::loadApps(Array)
#31 /volume1/web/nextcloudnew/lib/base.php(1068): OC::init()
#32 /volume1/web/nextcloudnew/console.php(46): require_once(‘/volume1/web/ne…’)
#33 /volume1/web/nextcloudnew/occ(11): require_once(‘/volume1/web/ne…’)
#34 {main}PHP Fatal error: Uncaught OCP\AppFramework\QueryException: Could not resolve defaultTokenProvider! Class defaultTokenProvider does not exist in /volume1/web/nextcloudnew/lib/private/AppFramework/Utility/SimpleContainer.php:110
Stack trace:
#0 /volume1/web/nextcloudnew/lib/private/AppFramework/Utility/SimpleContainer.php(125): OC\AppFramework\Utility\SimpleContainer->resolve(‘defaultTokenPro…’)
#1 /volume1/web/nextcloudnew/lib/private/ServerContainer.php(132): OC\AppFramework\Utility\SimpleContainer->query(‘defaultTokenPro…’)
#2 /volume1/web/nextcloudnew/lib/private/AppFramework/Utility/SimpleContainer.php(81): OC\ServerContainer->query(‘defaultTokenPro…’)
#3 /volume1/web/nextcloudnew/lib/private/AppFramework/Utility/SimpleContainer.php(104): OC\AppFramework\Utility\SimpleContainer->buildClass(Object(ReflectionClass))
#4 /volume1/web/nextcloudnew/lib/private/AppFramework/Utility/SimpleContainer.php(125): OC\AppFramework\Utility\SimpleContainer->resolve(‘OC\\Authenticati…’)
#5 /volume1/web/nextcloudnew/lib/private/Serve in /volume1/web/nextcloudnew/lib/private/AppFramework/Utility/SimpleContainer.php on line 110
Aber jetzt…
mit dem < Zeichen vor Buchstabensalat wurde Buchstabensalat hier beim posten einfach aus der Befehlskette gelöscht…
sudo -u http /usr/local/bin/php70 -c /var/packages/WebStation/etc/php_profile/Buchstabensalat/conf.d/user_settings.ini -f /volume1/web/cloud/occ db:add-missing-indices
… hier der vollständige Befehl:
sudo -u http /usr/local/bin/php70 -c /var/packages/WebStation/etc/php_profile//conf.d/user_settings.ini -f /volume1/web/cloud/occ db:add-missing-indices
Auch von mir vielen Dank für den Beitrag!
Leider hat es bei mir nicht ganz funktioniert aber durch deinen Beitrag und das Synology-Forum bin ich auf die Lösung gekommen.
Für alle über den Aufgabenplaner der Synology die occ-Befehle (bspw: occ db:add-missing-indices) oder den conjob ausführen möchten, hier die Lösung die bei mir geklappt hat:
sudo -u http /usr/local/bin/php70 -c /var/packages/WebStation/etc/php_profile//conf.d/user_settings.ini -f /volume1/web/cloud/occ db:add-missing-indices
Sehr cool! Vielen Dank für diesen Beitrag!!