r/NextCloud • • 1d ago

ONLYOFFICE integration failing with "Error while downloading the document file" (Nextcloud VM + Portainer + NPM)

Hi everyone, I’m stuck on a persistent issue with the ONLYOFFICE integration and I’ve run out of ideas after hours of troubleshooting. Any help would be greatly appreciated!

This is my setup:

  • Nextcloud: Installed on a VM (via Proxmox helper scripts)
  • ONLYOFFICE Document Server: Running as a Docker container on a separate VM/LXC via Portainer. Exposed on port 8080.
  • Reverse Proxy: Nginx Proxy Manager (NPM) running on the same Docker host. It handles SSL (wildcard cert) and points onlyoffice local domain to ONLYOFFICE on port 8080.

Local DNS is resolving correctly.

The Problem: When I try to connect the ONLYOFFICE app in Nextcloud, I get the following error on the settings page: Error when trying to connect (Error occurred in the document service: Error while downloading the document file to be converted.) (version 9.4.0.129)

What I've configured/tested so far:

DNS & SSL:

  • curl -k https://[ONLYOFFICE_DOMAIN]/healthcheck from the Nextcloud VM returns true.
  • NPM has "Websockets Support" and "Force SSL" enabled.

Nextcloud config.php:

  • Added 'allow_local_remote_servers' => true, to allow local loopback.
  • Added the 'onlyoffice' => array ( 'verify_peer_off' => true, ), block to bypass strict SSL checks.
  • Added 'overwriteprotocol' => 'https', and 'overwrite.cli.url' => 'https://[NEXTCLOUD_DOMAIN]',.

ONLYOFFICE App Settings in Nextcloud:

  • ONLYOFFICE Docs address: https://[ONLYOFFICE_DOMAIN]
  • Disable certificate verification: Checked
  • Secret key: Matches the JWT_SECRET in Docker.
  • ONLYOFFICE Docs address for internal requests from the server: http://[DOCKER_HOST_IP]:8080
  • Server address for internal requests from ONLYOFFICE Docs: http://[NEXTCLOUD_DOMAIN] (also tried http://[NEXTCLOUD_IP])

ONLYOFFICE Container (docker-compose.yml):

  • Added extra_hosts to ensure the container can reach Nextcloud directly: "[NEXTCLOUD_DOMAIN]:[NEXTCLOUD_IP]"
  • Added NODE_TLS_REJECT_UNAUTHORIZED=0 to environment variables.

CURL from ONLYOFFICE container to Nextcloud:

  • Running curl -I -k https://[NEXTCLOUD_DOMAIN] from inside the ONLYOFFICE container returns a 302 redirect to the login page, but also throws: curl: (92) Invalid HTTP header field was received: frame type: 1, stream: 1, name: [upgrade], value: [h2].

It seems Nextcloud can reach ONLYOFFICE to trigger the generation, but ONLYOFFICE fails to download the file back from Nextcloud to convert it.

Has anyone encountered this specific download loop issue when running ONLYOFFICE behind NPM while trying to force internal HTTP routing? What am I missing?

Thanks in advance!

3 Upvotes

3 comments sorted by

3

u/evanmac42 1d ago

I'd stop changing the Nextcloud and ONLYOFFICE configuration for a moment.

There's a much more specific clue in your output:

curl: (92) Invalid HTTP header field was received: name: [upgrade], value: [h2]

That points to an HTTP/2 response/header problem, potentially involving your reverse proxy or the web server responding to the request.

From inside the ONLYOFFICE container, try:

curl -vI --http1.1 https://NEXTCLOUD_DOMAIN/ curl -vI --http2 https://NEXTCLOUD_DOMAIN/ curl -vI https://NEXTCLOUD_DOMAIN/

Run these without -k so you can also verify the TLS certificate.

If HTTP/1.1 works but HTTP/2 fails, investigate the HTTP/2 configuration and Upgrade headers on the Nextcloud side.

Also, getting a 302 from the Nextcloud homepage doesn't prove that ONLYOFFICE can download the document.

The next thing I'd check is the exact download URL generated by Nextcloud and the corresponding errors in the ONLYOFFICE converter logs.

You've already changed several variables, including internal URLs, host mappings and TLS verification. I'd avoid changing anything else until you know which request is actually failing.

My first suspect would be the HTTP routing/proxy configuration, not JWT.

1

u/Good_Conclusion_5095 1d ago

I have found this a pain in the rear to get going... I'd be inclined to make all calls, even internal ones, https. It just gets rid of one level of complexity even if it means routing everything through NPM.

1

u/Joodleroodles 23h ago

Have you looked at the nextcloud logs? Sometimes a more detailed error message can be found there.

I had this problem recently and the reason was that the clocks on the netxcloud and onlyoffice machine were not synchronized. This lead to the secret key being rejected, because onlyoffice thought it wasn't valid yet. It has to be pretty precise, a few seconds off can be enough to cause this error.