search

nextcloud / richdocuments

📑 Collabora Online for Nextcloud
https://nextcloud.com/collaboraonline
361 stars 118 forks source link

Office documents not opening with one Nextcloud server although they do with an apparently identical older but updated Nextcloud server. #2716

Closed kocherjj closed 1 year ago

kocherjj commented 1 year ago

Describe the bug A clear and concise description of what the bug is. I have two Nextcloud 25.0.2 servers, each running in its own LXC. I have two CODE servers, each running in its own LXC on the same Proxmox host as the Nextcloud servers. All 4 servers are on the same Proxmox hypervisor, in the same DMZ subnet, OS updated to Ubuntu 22.04 Server and fully up to date, with a Caddy reverse proxy in front of them handling HTTPS.

Cloud server 1 has been running for a few years, updated regularly. It has been working consistently for document editing via CODE server 1 for almost a year. Cloud server 2 is a fresh server I setup for a local volunteer organization. I first tried to use the "Groups" option in CODE so I could have just a single Collabora server, and this did not work. When I enter the URL for CODE server 1 in the Cloud server 2 Office Administration settings, I get a Green checkmark and a message that the "Collabora Online server is reachable". This is identical behavior to Cloud server 1 but when I attempt to open a document, I get the "Loading" message and spinning wheel for a while, and then "Document loading failed"

Since I don't want to mess up the working instance I created a 2nd CODE server and configured it specifically for Cloud 2. This did not help. I can point Cloud 1 at either of the CODE servers and it connects and functions, but Cloud 2 will not connect to either but behaves the same. Green checkbox and "Collabora Online server is reachable" message but every document fails to open.

I have setting up several other test servers, both Nextcloud and CODE, using various tutorials and even just poking the options myself hoping for a miracle, and nothing works. At this point the anomaly appears to be the single working instance I have.

To Reproduce Steps to reproduce the behavior: Step 1: Create an Ubuntu 22.04 based LXC and follow the official documentation to install and configure a Nextcloud 25.0.2 server. Step 2: Create an Ubuntu 22.04 based LXC and follow the official documentation to install and configure a CODE 22.05 server. Step 3: Configure the reverse proxy to take HTTPS from Nextcloud and forward it to port 9980 on the CODE server. Step 4: Enter the CODE server URL in the Nextcloud Admin/Office settings and save. Step 5: Attempt to create a new or open an existing office document.

Expected behavior A clear and concise description of what you expected to happen. I expect a new word document or spreadsheet to open in the browser or mobile app for editing just like it does with my other cloud server.

Screenshots If applicable, add screenshots to help explain your problem.

Client details:

Server details

Operating system: Ubuntu 22.04 Server

Web server: Apache 2.4.52

Database: MariaDB 10.6

PHP version: 8.1

Nextcloud version: 25.0.2

Version of the richdocuments app 7.0.2

Version of Collabora Online 22.05

Logs #### Nextcloud log (data/nextcloud.log) ``` Nothing new shows up in nextcloud.log when I attempt and fail to open an office document ``` #### Browser log ``` Insert your browser log here, this could for example include: a) The javascript console log Javascript console log is identical between the two servers whether the document opens successfully or not, except that on Server 2 where it fails the last line is 'FAILED Office.vue:199' but in the server that works the last line is 'Error during post message handler postMessage.tsx:97'. The document opens fine on server 1 despite the error. b) The network log c) ... ``` ####Other Logs In either of my CODE servers I see the same items logged whethere a document loads or fails to load, except that these 9 lines appear in the logs only when I attempt to open a document using any server other than the working one. ``` Jan 02 10:53:59 collabora2 coolwsd[4516]: wsd-04516-04550 2023-01-02 10:53:59.076365 -0500 [ docbroker_003 ] ERR WOPI::CheckFileInfo failed for URI [https://cloud.domain2.net/index.php/apps/richdocuments/wopi/files/671_ocdap12jokzu?access_token=OQv7NDF4UspmdmTEQSdRS0bs6IRFFhdN&access_token_ttl=1672710778000&permission=edit]: 0 . Headers: Body: []| wsd/Storage.cpp:687 Jan 02 10:53:59 collabora2 coolwsd[4516]: wsd-04516-04550 2023-01-02 10:53:59.076564 -0500 [ docbroker_003 ] ERR loading document exception: WOPI::CheckFileInfo failed: | wsd/DocumentBroker.cpp:2339 Jan 02 10:53:59 collabora2 coolwsd[4516]: wsd-04516-04550 2023-01-02 10:53:59.076623 -0500 [ docbroker_003 ] ERR Failed to add session to [https://cloud.domain2.net:443/index.php/apps/richdocuments/wopi/files/671_ocdap12jokzu] with URI [https://cloud.domain2.net/index.php/apps/richdocuments/wopi/files/671_ocdap12jokzu?access_token=OQv7NDF4UspmdmTEQSdRS0bs6IRFFhdN&access_token_ttl=1672710778000&permission=edit]: WOPI::CheckFileInfo failed: | wsd/DocumentBroker.cpp:2301 Jan 02 10:53:59 collabora2 coolwsd[4516]: wsd-04516-04550 2023-01-02 10:53:59.076678 -0500 [ docbroker_003 ] ERR Storage error while starting session on https://cloud.domain2.net:443/index.php/apps/richdocuments/wopi/files/671_ocdap12jokzu for socket #19. Terminating connection. Error: WOPI::CheckFileInfo failed: | wsd/COOLWSD.cpp:4734 Jan 02 10:53:59 collabora2 coolwsd[4516]: wsd-04516-04550 2023-01-02 10:53:59.076912 -0500 [ docbroker_003 ] ERR Failed to load document with URI [https://cloud.domain2.net/index.php/apps/richdocuments/wopi/files/671_ocdap12jokzu?access_token=OQv7NDF4UspmdmTEQSdRS0bs6IRFFhdN&access_token_ttl=1672710778000&permission=edit].| wsd/DocumentBroker.cpp:2322 Jan 02 10:53:59 collabora2 coolwsd[4516]: wsd-04516-04550 2023-01-02 10:53:59.076967 -0500 [ docbroker_003 ] ERR loading document exception: Failed to load document with URI [https://cloud.domain2.net/index.php/apps/richdocuments/wopi/files/671_ocdap12jokzu?access_token=OQv7NDF4UspmdmTEQSdRS0bs6IRFFhdN&access_token_ttl=1672710778000&permission=edit].| wsd/DocumentBroker.cpp:2339 Jan 02 10:53:59 collabora2 coolwsd[4516]: wsd-04516-04550 2023-01-02 10:53:59.077013 -0500 [ docbroker_003 ] ERR Failed to add session to [https://cloud.domain2.net:443/index.php/apps/richdocuments/wopi/files/671_ocdap12jokzu] with URI [https://cloud.domain2.net/index.php/apps/richdocuments/wopi/files/671_ocdap12jokzu?access_token=OQv7NDF4UspmdmTEQSdRS0bs6IRFFhdN&access_token_ttl=1672710778000&permission=edit]: Failed to load document with URI [https://cloud.domain2.net/index.php/apps/richdocuments/wopi/files/671_ocdap12jokzu?access_token=OQv7NDF4UspmdmTEQSdRS0bs6IRFFhdN&access_token_ttl=1672710778000&permission=edit].| wsd/DocumentBroker.cpp:2301 Jan 02 10:53:59 collabora2 coolwsd[4516]: wsd-04516-04550 2023-01-02 10:53:59.077062 -0500 [ docbroker_003 ] ERR Error while starting session on https://cloud.domain2.net:443/index.php/apps/richdocuments/wopi/files/671_ocdap12jokzu for socket #31. Terminating connection. Error: Failed to load document with URI [https://cloud.domain2.net/index.php/apps/richdocuments/wopi/files/671_ocdap12jokzu?access_token=OQv7NDF4UspmdmTEQSdRS0bs6IRFFhdN&access_token_ttl=1672710778000&permission=edit].| wsd/COOLWSD.cpp:4744 Jan 02 10:53:59 collabora2 coolwsd[4516]: wsd-04516-04550 2023-01-02 10:53:59.084316 -0500 [ docbroker_003 ] ERR #29: Read failed, have 0 buffered bytes (ECONNRESET: Connection reset by peer)| net/Socket.hpp:1133 ```

What else can I be looking at to identify the issue? As far as I can tell the Nextcloud servers are configured identically with the exception of the actual hostnames and IP addresses, and the CODE servers are as well.

Since Cloud 1 works with both CODE servers this does not appear to be a Collabora, DNS, or reverse proxy issue.

Since both Cloud servers work fine when a demo server is selected, this does not appear to be an app or Nextcloud issue.

Since the firewalls are all configured the same, and I've even tested with all firewalls disabled without any change, this does not appear to be a network issue.

Since nothing else is left then one of these assumptions has to be false or I'm missing another variable.

kocherjj commented 1 year ago

In case anyone with a similar issue finds this, this ended up being a DNS issue. With some assistance from another forum I eventually found that for some reason the return traffic to Could 2 was being forwarded to an external IP instead of my reverse proxy, and my router was rejecting it since it was on the internal side. The correct routes seemed to be in place on my DNS server but after trying to resolve this in other ways I eventually removed the DNS entries completely and re-added them, and everything is working now.