Nach dem Update erhalte ich unter der Administrations-Übersicht folgenden Fehler:
Der Webserver ist noch nicht hinreichend für Datei-Synchronisierung konfiguriert, da die WebDAV-Schnittstelle vermutlich nicht funktioniert. Damit diese Prüfung ausgeführt werden kann, muß sichergestellt sein, dass der Webserver eine Verbindung zu sich selbst herstellen kann. Daher muss er in der Lage sein, mindestens eine seiner trusted_domains oder overwrite.cli.url aufzulösen und eine Verbindung zu ihnen herzustellen. Dieser Fehler kann das Ergebnis einer serverseitigen DNS-Nichtübereinstimmung oder einer ausgehenden Firewall-Regel sein.
Habe die Anweisungen in der User Doku befolgt sowie im Internet recherchiert, aber keine Lösung gefunden. In der der config.php sind die Werte trusted_domains und overwrite.cli.url korrekt gesetzt. Aber ich bekomme den Fehler nicht weg und kann somit seit Wochen nicht mehr über Webdav auf die Daten zugreifen.
Die Nextcloud liegt bei all-inkl.com
Hat jemand eine Idee woran das liegen konnte. Vor dem Update lief alles.
Hat es einen besonderen Grund, warum du in trusted_domains nextcloud als SubDomain und in overwrite.cli.url als Unterverzeichnis angibst? Kann das funktionieren?
Das hat bisher immer funktioniert. Und in der Doku war das auch so beschrieben.
Wie sollte ich das deiner Meinung nach eintragen? Kann das ja mal testen, ob dass das Problem beseitigt.
Für mich stellt sich die Frage, welches von beiden denn stimmt? Ist dein NC nun über eine SubDomain oder ein Verzeichnis erreichbar oder gar tatsächlich beides?
Ja, genau NC ist über beides erreichbar
Wie schaut denn der Bereich zu WebDAV “location ^~ / well-nown” in ihrer Nextcloud.conf nach dem Update jetzt aus.
(Ich schlage vor wir schauen uns diese Einträge als nächstes an)
Hier ist ein Beispiel aus meiner Testumgebung NC31.0.4 mit NGINX
Datei:
nano /etc/nginx/conf.d/nextcloud.conf
location ^~ /.well-known {
location = /.well-known/carddav { return 301 /remote.php/dav/; }
location = /.well-known/caldav { return 301 /remote.php/dav/; }
location /.well-known/acme-challenge { try_files $uri $uri/ =404; }
location /.well-known/pki-validation { try_files $uri $uri/ =404; }
return 301 /index.php$request_uri;
}
Gibt es da Unterschiede zu Ihrer Datei?
Ich würde mich auf eine Zugriffsvariante festlegen, wenn keine zwingenden Gründe vorliegen.
Soll ich dann in der Config den Eintrag overwrite.cli.url => https://nextcloud.xxx.de ändern, oder was ist hier mit eine Zugriffsvariante gemeint?
Hier läuft der Apache, da sieht .htaccess anders aus, hatte ich mir das bereits mal angeschaut
Hier ein Auszug:
<IfModule mod_rewrite.c>
RewriteEngine on
RewriteCond %{HTTP_USER_AGENT} DavClnt
RewriteRule ^$ /remote.php/webdav/ [L,R=302]
RewriteRule .* - [env=HTTP_AUTHORIZATION:%{HTTP:Authorization}]
RewriteRule ^\.well-known/carddav /remote.php/dav/ [R=301,L]
RewriteRule ^\.well-known/caldav /remote.php/dav/ [R=301,L]
RewriteRule ^remote/(.*) remote.php [QSA,L]
RewriteRule ^(?:build|tests|config|lib|3rdparty|templates)/.* - [R=404,L]
RewriteRule ^\.well-known/(?!acme-challenge|pki-validation) /index.php [QSA,L]
RewriteRule ^ocm-provider/?$ index.php [QSA,L]
RewriteRule ^(?:\.(?!well-known)|autotest|occ|issue|indie|db_|console).* - [R=404,L]
</IfModule>
habe ich mal testweise gemacht, hat leider nichts gebracht.
Ich bin ein Subdomain Freund und wie ich finde bringt es keine ungewollte und plötzlich auftretende Unruhe rein.
Ja, Einfach mal ausprobieren.
Vorher immer erst eine Backupdatei erstellen^^
Ihre Subdomain hat keine Probleme beim dns-auflösen?
Haben sie die folgenden blöcke mal umgebaut und getestet?
Beides sollte mit ihrer config.php harmonisieren (subsite oder Subdomain) oder wie bei ihnen beides.
Sie könnten mit den folgenden Beispielen mal herum probieren, Apache neu starten und schauen wie ihre nextcloud reagiert.
Beispiel als subdomain
RewriteRule ^.well-known/carddav /remote.php/dav [R=301,L]
RewriteRule ^.well-known/caldav /remote.php/dav [R=301,L]
Beispiel als subsite
RewriteRule ^.well-known/carddav /nextcloud/remote.php/dav [R=301,L]
RewriteRule ^.well-known/caldav /nextcloud/remote.php/dav [R=301,L]
Habe soeben auf 31.0.6 upgedatet, hier ist der Bug anscheinend behoben worden und es funktiert wieder.
