Da sind sie wieder! Nach dem Upgrade auf Nextcloud 14 galt es auch hier wieder neu auftauchende Fehlermeldungen zu beseitigen.
Der „X-Frame-Options“-HTTP-Header ist nicht so konfiguriert, dass er „SAMEORIGIN“ entspricht. Dies ist ein potentielles Sicherheitsrisiko und es wird empfohlen, diese Einstellung zu ändern.
In der Datenbank fehlen einige Indizes. Auf Grund der Tatsache, dass das hinzufügen von Indizes in großen Tabellen einige Zeit in Anspruch nehmen wird, wurden diese nicht automatisch erzeugt. Durch das Ausführen von „occ db:add-missing-indices“ können die fehlenden Indizes manuell hinzugefügt werden, während die Instanz weiter läuft. Nachdem die Indizes hinzugefügt wurden, sind Anfragen auf die Tabellen normalerweise schneller.
- 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“.
Der „Referrer-Policy“ HTTP-Header ist nicht gesetzt auf „no-referrer“, „no-referrer-when-downgrade“, „strict-origin“ oder „strict-origin-when-cross-origin“. Dadurch können Verweis-Informationen preisgegeben werden. Siehe die W3C-Empfehlung.
Um die erste Fehlermeldung zu beseitigen, wurde im Virtual Host mit
1 |
# nano /etc/apache2/sites-available/nextcloud.conf |
die vorhandene Zeile
1 |
Header append X-FRAME-OPTIONS "SAMEORIGIN" |
entfernt. Darunter fügt man an dieser Stelle
1 |
Header set Referrer-Policy "no-referrer-when-downgrade" |
ein und auch die dritte Fehlermeldung verschwindet nach dem Neustart des Webservers.
1 |
# /etc/init.d/apache2 restart |
Um das Datenbank-Problem zu lösen, wechselt man ich das Hauptverzeichnis der Nextcloud
1 |
# cd /var/www/html/nextcloud |
und führt
1 |
sudo -u www-data php occ db:add-missing-indices |
aus. Die erfolgreiche Bestätigung sollte dann so aussehen:
1 2 3 4 5 6 7 |
Check indices of the share table. Adding additional share_with index to the share table, this can take some time... Share table updated successfully. Adding additional parent index to the share table, this can take some time... Share table updated successfully. Adding additional mtime index to the filecache table, this can take some time... Filecache table updated successfully. |
Zum Schluss sind alle Überprüfungen bestanden und die Nextcloud darf wieder produktiv genutzt werden.
Viel Spaß!
Die Datei „/etc/apache2/sites-available/nextcloudcloud.conf“ existiert bei mir nicht… 😉
Mal über Software nachgedacht, die NICHT alle paar Wochen kaputt geht?
Wenn die Datei nicht existiert, kann ich sie dir schicken. 😁
Und, nö, habe noch nicht über Software nachgedacht, die nicht alle paar Wochen kaputt geht. Worüber sollte ich sonst schreiben?
danke für die anleitung. alles wieder im grünen bereich, nc 14.0.1 🙂
Super!
Bei mir wirft die Konsole folgenden Fehler aus: „This version of Nextcloud requires at least PHP 7.0You are currently running 5.5.9-1ubuntu4.26. Please update your PHP version.“
Der Server selbst läuft mit PHP 7.0.32 und auch im Nextcloud Backend wird PHP 7.0.32 angezeigt. Was mache ich falsch?
Das ist komisch. Hast Du denn den Webserver schon neu gestartet? Bei mir läuft z.B. PHP 7.0.30. Möglich ist natürlich auch, dass ein Paket fehlt. So etwas ist aus der Ferne ntürlich schwer einzuschätzen.
Ja, den Server habe ich komplett neugestartet und PHP5 sogar komplett deinstalliert. Leider ohne Besserung. Die anderen Fehlermeldungen konnte ich dank deines Beitrages beheben.
Und wie sieht die .htaccess aus?
Ich habe dasselbe Problem wie Philipp.
Was bedeutet Deine Frage? Was muss denn mit .htaccess sein?
Ich Frage mal so: Von was für einem System reden wir?
Guten Morgen,
Ich bekomme ebenfalls die Meldung „Fehlender Index „fs_mtime“ in der Tabelle „oc_filecache“ in meiner frisch augesetzten NC14.0.1-Installation, allerdings gibt es in meiner Tabelle „oc_filecache“ keine „fs_mtime“ sondern nur „mtime“. Ich habe für „mtime“ einen Index angelegt, bekomme jedoch weiterhin die oben genannte Sicherheitswarnung in Nextcloud. Kann es sein dass es sich hierbei um einen Deaklarierungsfehler in NC handelt?
Hast Du denn einmal den entsprechenden Befehl ausgeführt?
Guten Morgen intux,
Ja hatte ich, allerdings hatte dies in meinem Fall nix bewirkt. Ich habe allerdings inzwischen manuell mtime in fs_mtime umbenannt. Seitdem klappt alles.
Guten Morgen Carl,
na bestens, die Fehlermeldung ist nun weg?
Wenn ich bei mir occ ./db:add-missing-indices eingebe, kommt bei mir die Meldung command not found.
Ich sehe aber die Datei occ
Was mache ich falsch ??
Und wenn ich das hier eingebe
sudo -u www-data php occ db:add-missing-indices
Kommt die Meldung:
sudo: unknown user: www-data
sudo: unable to initialize policy plugin
Wer ist denn der Besitzer der Nextcloud-Verzeichnisses?
Sorry, habe den falschen Code kopiert, sollte heissen . sudo -u httpa php occ db:add-missing-indices
Habe es schon im Synology Forum gepostet. Aber dort komme ich auch nicht weiter.
Eine komplett neue Installation funktioniert wunderbar, aber sobald ich die Datenbank wieder vom Backup einspiele kommt die Meldung wieder. Auszug vom Synology Forum.
root@DS1817:~# /bin/su -s /bin/sh -c „/usr/local/bin/php70 -f /volume1/web/nextcloudnew/occ db:add-missing-indices“ http
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\Serve r))
#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\Serve r))
#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\Serve r))
#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 notresolve 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
Was mache ich denn, wenn ich keine Möglichkeit habe, Befehle abzusetzen weil nextcloud in einem WebSpace installiert ist (bitte jetzt nicht die Antwort, dass ich es auf einem eigenen Server installieren soll) und ich nur per FTP darauf zugreifen kann.
Somit ich weder SUDO absetzen kann, noch eine Datei /etc/apache2/sites-available/nextcloudcloud.conf habe.
Ich war vor einiger Zeit mit OwnCloud 5 bei all-inkl.com. Ich konnte damals einiges via .htaccess-Datei konfigurieren. Ich denke, dass du so einiges auch manchen kannst. Ansonten bemühe dort doch den Support.
Auch wenn Du es nicht hören willst, aber ein Raspberry Pi ist eine gute Alternative. Gerade weil man hier Datenmengen speichern kann die dir sonst kein Hoster bieten wird. So ein RasPi ist schnell eingerichtet.
Danke
Hallo kann mir einer mit dieser Fehlermeldung weiterhelfen.
Wenn ich occ ausführen möchte kommt das hier:
root@nextcloud:/var/www/nextcloud# sudo -u www-data php occ
PHP Warning: require_once(): open_basedir restriction in effect. File(/var/www/nextcloud/console.php) is not within the allowed path(s): (/dev/urandom) in /var/www/nextcloud/occ on line 11
PHP Warning: require_once(/var/www/nextcloud/console.php): failed to open stream: Operation not permitted in /var/www/nextcloud/occ on line 11
PHP Fatal error: require_once(): Failed opening required ‚/var/www/nextcloud/console.php‘ (include_path=‘.:/etc/php/7.0/:/var/www/nextcloud/
;
; Windows: \path1′) in /var/www/nextcloud/occ on line 11
Hallo Tino,
auf was für einem System werkelt denn die Nextcloud?
Habe einen Pi2 mit raspbian (stretch).
Genau wie bei dir ist der Fehler nach einem Update auf 14.02 erschienen, den ich mit occ db:add-missing-indices beheben wollte.
Wie es scheint gibt es ein Problem bei ausführen der console.php. Ich vermute hier ein Problem mit den include_path. Kann aber auch was ganz anderes sein.
Hab bei Dr. google nicht viel sinvolles gefunden.
Nebenbei: Die Datei /etc/apache2/sites-available/nextcloudcloud.conf kann ich nicht finden, nur diese /etc/apache2/sites-available/nextcloud.conf. Und hier gibt es keine Zeile „Header append X-FRAME-OPTIONS „SAMEORIGIN“.
Fehler gefunden:
Das Problem war in einer php.ini in /etc/php/
Dort war ein Eintrag nicht auskommentiert /dev/urandom
Gefunden hier:
forum howtoforge de/threads/owncload-und-openbase-dir-restriction-ispconig-3-1-owncloud-10-1-6.10956/
Super! Eigentlich ist das komisch, da die php.ini garnicht angefasst werden muss.
Übrigens zu „Nebenbei:“, die Datei heißt bei mir auch nextcloud.conf. Das passe ich im Artikel noch an.
So jetzt habe ich nur noch eine Fehlermeldung:
„Dein Web-Server ist nicht richtig eingerichtet um „/.well-known/caldav“ aufzulösen. “
Das ist bei mir nicht relevant, da ich keinen Client nutze der das haben möchte (ich schätze das brauch nur Apfel Sotware).
Wäre schön diese auch noch weg zu bekommen. Im Netz gibt es viele Hinweise aber die führen bei mir nicht zum Erfolg. Ich schätze die redirect Anweisung steht nich in der richtigen Datei bzw. nich an der richtigen Stelle.
PS: Die Seite (auch die Themen) gefällt mir.
Gruß nach Halle
Hallo Tino,
schau mal hier: https://docs.nextcloud.com/server/14/admin_manual/issues/general_troubleshooting.html#service-discovery
Über CalDAV synchronisierst Du Kalender, auch mit Android, Linux, Windows, Mac OS etc.
Hallo intux,
danke für den Hinweis, die Seite wird auch in dem Warnhinweis angegeben. Das dort angegebene Redirect habe ich auch in die .htaccess eingetragen, nur ohne Erfolg. Es ging mir nur um die Fehlermeldung, denn „Some clients – especially on iOS/macOS – have problems finding the proper sync URL, even when explicitly configured to use it.“. Genau diese setze ich aber nicht ein.
Ich nutze die Nextcloud vornehmlich für CalDAV CardDAV und WebDAV auf Android und Linux. Damit bleibt die Familie sync 😉
Nebenbei, ich habe auch Prosody auf dem System (Familien-chat), der Pi ist ja immer an.
Das sollte aber keine Auswirkung auf Nextcloud haben!?
Das mit der Fehlermeldung ist schon komisch. Wir könnten ja theoretisch unsere .htaccess mal abgleichen. Schreib mich ruhig via XMPP an.
Prosody nebenbei auf dem Pi 2 parallel zur Nextcloud laufen zu lassen, finde ich vom Gefühl her schon etwas kritisch. Ich denke aber, dass Du das gut überwachst. Du wirst sehen, ob es auf Dauer funktioniert! Ich könnte mir schon vorstellen, dass der Swap regelmäßig überläuft, weil der RAM nicht ausreicht. Das ist aber nur mein Gefühl. Getestet habe ich das so noch nicht.
Danke für die Hilfestellung.
Werde nachher meine .htaccess mal zu dir senden.
Wenn ich mal auf das System schaue und mir die Ramauslastung ansehe fällt mir nix bezüglich Füllstand auf, sind auch nur 3-4 Konten auf Prosody und Nextcloud -> Familie halt. Der Rest ist auf einem großen NAS (x86) mit OMV (WakeOnLan)
Du kannst mal versuchen Deine Cloud nicht als Subfolder sondern über eine Subdomain anzusteuern. Dazu packst Du das Nextcloud-Verzeichnis in /var/www/html/ und passt DocumentRoot im Virtualhost so an, dass Du Deine Nextcloud mit cloud.domain.tld erreichst. Der Vorteil hierbei ist, dass du im Security-Test auch ein A+ erreichst. Über den Subfolder domain.tld/cloud bekommst du nur ein A.
Ich denke, dass die Fehlermeldung dadurch verschwindet. Teste das mal!
So mit intux Hilfe konnte das Problem („Dein Web-Server ist nicht richtig eingerichtet um „/.well-known/caldav“ aufzulösen. “) gelöst werden.
Hier nochmal ein herzliches Danke an intux für die unkomplizierte und schnelle Hilfe.
Das Proble lag am Alias in der /etc/apache2/sites-available/nextcloud.conf
Alias /nextcloud „/var/www/nextcloud/“ -> Alias / „/var/www/nextcloud/“
Ende gut, alles gut!