leider bemerke ich es erst heute: Seit 7 Tagen öffnet COOL keine Dokumente mehr. Klickt man ein Dokument an, erscheint nach einiger Zeit “Laden des Dokuments fehlgeschlagen”.
Bei welchen Anbieter? Was für ein Server? lokal
Auf welcher Hardware? PC
Betriebssystem Ubuntu 24.04
Nextcloud Version: 29.0.7.1
PHP Version: 8.3
Welche Datenbank? MariaDB 11.4.3
Nginx 1.27.1
In den acess.logs vom nginx sehe ich, dass es vor 7 Tagen noch einwandfrei lief. Leider sind diese Woche ja einige Update reingekommen und u. a. auch eines von coolwsd (24.04.7.2-1).
In der access.log endet der Aufruf “POST /browser/cool.html?WOPISrc=…” mit Code 404 (Not Found). Wie gesagt vor einer Woche war es noch Code 200 (OK).
Wenn ich die Aufrufe vergleiche, so sehe ich einen Unterschied: Bis vor einer Woche endeten sie mit “… HTTP/1.1”. Jetzt mit “… HTTP/2.0”. Deshalb habe ich im Reverse Proxy die Zeile “http2 on;” mit aufgenommen.
Ich habe jetzt stundenlang alles abgesucht und nichts gefunden. Am Ende habe ich den Produktiv-Server aus Verzweiflung durchgestartet. Keine Veränderung.
Habe ein ähnliches Problem und es scheint als gäbe es schon länger und mehrere Probleme mit dieser App.
Ich nutze keinen Server und habe seit einiger Zeit hunderte Error, obwohl die App gar nicht installiert ist. Was ich zum Thema lokaler Office Server finden konnte, ist, das der Aufruf im Hintergrund wohl in der Funktion die in der nextcloud config.php hinterlegte override_cli_url benutzt. Eventuell müsstest du diese anpassen. Ob dort nun localhost, die interne ip oder der fqdn rein muss, kann ich dir nicht sagen. Müsste man mal testen
Nein, die override_cli_url habe ich gerade noch mal kontrolliert. Die müsste stimmen. Mit der ging es vor einer guten Woche ja auch. Und eigentlich sieht man sie auch im HTTP-POST in der access.log.
Was mich so irritiert ist, dass es außer dem Code 404 keine weitere Fehlermeldung gibt.
Frage ist für mich deshalb: “Was an dem POST wird nicht gefunden?”
Der POST mit 404 ist der Versuch des CODE Servers die in der NC gespeicherte Datei zu öffnen - es scheint nicht (mehr) zu gehen. 404 ist ein error code vom Webserver - d.h. im Webserver log der Nextcloud (oder ggf Reverse Proxy) sollte man diesen Request sehen… aber evtl nicht per default - oft muss man access logs extra einschalten weil sie gern gross werden.
Stimmt, in der acces.log sehe ich die reversproxy aufrufe gar nicht. Vielleicht tappe ich deshalb so blind herum.
Dank des genialen Collabora integration guides habe ich das Nextcloud Office in den Sommerferien überhaupt erst zum Laufen bekommen. Vielen Dank für die hervorragende Arbeit!!!
In der nächsten ruhigen Minute werde ich mich noch mal dadurch arbeiten und systematisch suchen.
Ich bin dem Problem jetzt wohl einen Schritt näher: Ich weiß jetzt, was nicht gefunden wird.
Und zwar ist es mir klar geworden, als ich die Ausgabe von
occ richdocuments:activate-config
sah. Die “Configured WOPI URL” ist korrekt mit Port angegeben.
Die “Configured public WOPI URL” hingegen ohne Port.
Und in der access.log sehe ich die Ports ja nicht. Also habe ich die Netzwerkanalyse von Firefox versuchten Öffnen einen Dokumnets mitlaufen lassen. Und siehe da der 404 entsteht, weil “/browse/…” ohne Port angefordert wird. Also wahrscheinlich über die “public WOPI url”. Doch wo kann ich sie einstellen?
Jetzt habe ich über
occ config:app:set richdocuments public_wopi_url --value “…”
die public_wopi_url gesetzt. In der Ausgabe von
occ richdocuments:activate-config
erscheint sie jetzt auch richtig. Allerdings wird laut Firefox Nextwerkanalyse “/browse/…” immer noch ohne Port aufgerufen, was natürlich zu einem 404 führt.
Ich bin über die beiden WOPI URL auch schon gestolpert und ich schätze man kann sie in der coolwsd.xml einstellen. Ich vermute das soll helpfen wenn jemand auf biegen und brechen internen Zugriff anders regeln möchte…
Ich würde generell davon abraten unterschiedliche URLs, Ports usw zu verwenden - die Fehlersuche ist dann enorm kompliziert… ich empfehle 101: Split-Brain DNS (split-horizon) - die URLs und Ports bleiben damit gleich, so dass es keinen logischen Unterschied zwischen internen und externen Zugriffen gibt - KISS und die Fehlersuche ist einfacher…
du hast es nicht geschrieben ich probiere deswegen meine Kristallkugel
vermutlich hast du einen speziellen Port für CODE konfiguriert der in bestimmten Szenarien nicht verwendet wird. Die Zugriffe ohne Port verwenden den default Port - bei https:// ist es dann :443. du hast ja beim Reverse Proxy oder Webserver einen “Listener” konfiguriert, der an bestimmte Ports gebunden ist… d.h. sobal du die Verbindung in dem Server Log siehst weisst du dass die Verbindung über den entsprechenden Port reingekommen ist… in den F12 Tools des Browsers siehst du den Port mE auch hier Firefox:
Ich würde wenn möglich :443 verwenden weil man andere Ports häufig manchmal nicht erreichen kann (evtl. wird nur :443 für public WOPI URL supportet). Es hilft immer den Defaults zu folgen, weil diese manchmal (bewusst oder fehlerhaft) Annahmen umsetzen, die sonst kompliziert über Konfiguration implementiert werden müssen.
kann natürlich ein Caching Problem sein… sonst bleiben die Aussagen oben immer noch gültig.
Vielen Dank, für die tolle Unterstützung und die Zeit, die ihr aufwendet!!!
Ja, vielleicht habe ich etwas undeutlich geschrieben. Aber ich weiß erst seit gerade eben, dass es da zwei unterschiedliche WOPI URLs gibt. Die sollen natürlich gleich sein. Und es wundert mich, dass sie unterschiedlich waren.
Bisher sah ich die Eingabe der WOPI URL auch nur in der Oberfläche in den Einstellungen unter Office. Mich wunderte daher, dass es überhaupt zwei verschiedene gibt und dass sie plötzlich verschieden waren. Immerhin lief ja vor einer guten Woche noch alles.
Zur Aufklärung:
Die Nextcloud läuft unter Port 443. Und wir keine feste IP haben, läuft alles, was sonst eine Subdomain wäre, über einen eigenen Port. Deshalb der Port 9981, statt der Subdomain Office, der auf den reverse proxy geht. Von dort geht es local auf 9980. Dank der guten Anleitung lief das ja auch alles mal.
Jetzt fängt es an, drollig zu werden:
Direkt nach dem Setzen der URL über occ config:app:set richdocuments public_wopi_url --value “https://unserDomain.tld:9981” zeigte occ richdocuments:activate-config
🛈 Configured WOPI URL: https://unsereDomain.tld:9981
🛈 Configured public WOPI URL: https://unserDomain.tld:9981
an. Bei meiner Kontrolle gerade jetzt zeigt es die public WOPI URL wieder ohne Port an. Ich habe beide Ausgaben noch untereinander im Termial stehen. Wer oder was ändert heimlich die URL?
Dafür habe ich leider auch keine Lösung, ausser dass ich es, wie @wwe schon sagte, nicht so machen würde.
Grundsätzlich ist es überhaupt kein Problem, mehrere Subdomains zu verwenden mit einer dynamischen IP. Es muss lediglich für jede Subdomain ein CNAME-Record beim DNS-Provider deiner Domain eingerichtet werden, der dann auf den DynDNS-Namen verweist, der wiederum die aktuelle IP deines Internetanschlusses auflöst.
Beispiel:
cloud IN CNAME your.dyndnsname.tld.
office IN CNAME your.dyndnsname.tld.
Ja, stimmt, aber wenn man als Admin nicht auf einer grünen Wiese anfängt, muss man leider erstmal mit dem leben, was da ist. Eben mal schnell alles Bestehende umbauen geht nicht immer so einfach, vor allem, wenn dringliche Baustellen offen sind und die ManPower begrenzt ist.
Aber, ich bleibe dabei. Vor ca. 10 Tagen lief alles noch in genau der Konfiguration. Dann kamen ein paar Updates (ich glaube u.a. COOL und richdocuments) rein und schon geht es nicht mehr …
Eventuell kannst du ja deine Frage auch noch im Collabora Forum stellen und/oder hier einen Issue eröffnen, falls du denkst, dass es sich um einen Bug handelt.
So wie es für mich aussieht hat es weniger etwas mit COOL zu tun, als mit der App richdokuments, die ja in der Woche auch ein Update bekommen hat. Und es scheint mir, dass es seit dem nicht mehr läuft.
Und es ist ja auch offensichtlich, dass beim Aufruf von occ richdocuments:activate-config oder occ config:app:set richdocuments public_wopi_url etwas schief läuft.
Vor lauter Verzweiflung habe ich jetzt einen fiesen Dergel gemacht.
Ich habe im nginx den Server für coolwsd in den Server von der Nextcloud mit hineingesetzt. Natürlich auf die Gefahr hin, dass es unkontrollierbare Nebenwirkung hat.
Aber immerhin läuft das Office jetzt wieder.
Ich freue mich schon auf den Tag, an dem ich das wieder zurücknehmen kann.
Morgen am Brückentag sind nur ein paar Leute da und die lasse ich das Ganze mal testen. (Mir selbst traue ich nie. )
