NextCloud and Collabora on VM behind a single main Nginx Reverse Proxy - Document loading failed

Hoping for some help here. As noted in the subject, I am running on an Ubuntu 22.04 machine (an LXD Container) and have gotten Nextcloud running (several times now:) ) just fine.

At first I tried the built in Office CODE module and failed so I went to the separate package installer of Collabora CODE.

When I configure my Nextcloud App and try to access the collabora admin console they both work without error.

But creating documents fails with the dreaded “Document loading failed - Failed to load Nextcloud Office - please try again later” error.

I think the problem is the way I have my Nextcloud and Collabora apache2 virtual hosts defined on my ubuntu container AND SEPARATELY my nginx revers proxy.

On my Nextcloud/Collabora Server I have a virtual host block for my nextcloud installation. The expectation is the reverse proxy will be doing the ssl so I am listening on 80

<VirtualHost *:80>
ServerName nextcloud.my_domain.org

    ServerAdmin info@my_domain.org
    DocumentRoot /var/www/nextcloud

    Protocols h2 h2c http/1.1

    <IfModule mod_headers.c>
      Header always set Strict-Transport-Security "max-age=15552000; includeSubDomains"
    </IfModule>

    <Directory /var/www/nextcloud/>
            Require all granted
            AllowOverride All
            Options FollowSymLinks MultiViews

            <IfModule mod_dav.c>
                    Dav off
            </IfModule>
    </Directory>

    <FilesMatch ".php$">
     SetHandler "proxy:unix:/var/run/php/php8.1-fpm.sock|fcgi://localhost/"
    </FilesMatch>

    ErrorLog ${APACHE_LOG_DIR}/error.log
    CustomLog ${APACHE_LOG_DIR}/access.log combined

vim: syntax=apache ts=4 sw=4 sts=4 sr noet

And on my nginx reverse proxy with Let’s Encrypt certs I have the main Nextcloud server block

server {
server_name nextcloud.my_domain.org;
listen [::]:443 ssl http2; # managed by Certbot
listen 443 ssl http2; # managed by Certbot
ssl_certificate /etc/letsencrypt/live/nextcloud.my_domain.org/fullchain.pem; # managed by Certbot
ssl_certificate_key /etc/letsencrypt/live/nextcloud.my_domain.org/privkey.pem; # managed by Certbot
include /etc/letsencrypt/options-ssl-nginx.conf; # managed by Certbot
ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; # managed by Certbot

    client_max_body_size 0;
    underscores_in_headers on;

    # max-age=15552000
    # max-age=31536000
    add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;

    root /var/www/html;
    index index.html index.htm index.nginx-debian.html;

    location /.well-known/carddav {
        return 301 $scheme://$host/remote.php/dav;
    }

    location /.well-known/caldav {
        return 301 $scheme://$host/remote.php/dav;
    }

    location / {
            proxy_set_header Host $host;
            proxy_set_header X-Real-IP $remote_addr;
            proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
            proxy_set_header X-Forwarded-Proto $scheme;
            add_header Front-End-Https on;
            proxy_headers_hash_max_size 512;
            proxy_headers_hash_bucket_size 64;
            proxy_buffering off;
            proxy_redirect off;
            proxy_max_temp_file_size 0;
            add_header 'Content-Security-Policy' 'upgrade-insecure-requests';
            proxy_pass http://10.187.15.197:80;
    }

}

So my Nginx Reverse Proxy is running in the LXD protected subnet and gets its http and https connections requests at the main server and passes them into the LXD cloud to the reverse proxy.

HOLD ON A MINUTE… maybe I never passed the 8890 port through into the LXD cloud… let me check on that…

1 Like

I meant port 9980.

So, no that wasn’t it.

Going forward with my failing architecture.

Main Router:

  • Port forwards all incoming 80, 443 and 9980 to my LXD Server

LXD Server

  • The reverse proxy is running on the LXD network and I have punched all three ports above into the LXD network to the reverse proxy machine.

LXD Server - NGINX Reverse Proxy Machine

  • The reverse proxy uses the config noted in the first post to detect http://nextcloud.my_domain.org and https://nextcloud.my_domain.org and proxy pass them on to the lxd.nextcloud machine referenced by lxd ip address on port 80.

LXD Server - Nextcloud Machine Nextcloud Daemon

  • Seems to work fine for core Nextcloud stuff. I did all of the PHP caching and redis stuff.

LXD Server - Nextcloud Machine Collabora Daemon

  • Installed from packages.
  • I can configure Nextcloud App to see my collabora machine and it doesn’t error out.
  • I can reach the collabora admin console.

This is all done using the SINGLE apache virtual server because I think I did the proper routing in my nginx reverse proxy using this config

I went back to my rp and added this

LXD Server - NGINX Reverse Proxy Machine

server {
server_name collabora.my_domain.org;
listen 443 ssl; # managed by Certbot
ssl_certificate /etc/letsencrypt/live/collabora.my_domain.org/fullchain.pem; # managed by Certbot
ssl_certificate_key /etc/letsencrypt/live/collabora.my_domain.org/privkey.pem; # managed by Certbot
include /etc/letsencrypt/options-ssl-nginx.conf; # managed by Certbot
ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; # managed by Certbot

static files

location ^~ /browser {
proxy_pass http://10.187.15.197:9980;
proxy_set_header Host $http_host;
}

WOPI discovery URL

location ^~ /hosting/discovery {
proxy_pass httpcolon_slash_slash10.187.15.197:9980; ← had to get rid of the url to post
proxy_set_header Host $http_host;
}

Capabilities

location ^~ /hosting/capabilities {
proxy_pass http_colon_slash_slash_10.187.15.197:9980;
proxy_set_header Host $http_host;
}

main websocket

location ~ ^/cool/(.*)/ws$ {
proxy_pass http_colon_slash_slash_10.187.15.197:9980;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection “Upgrade”;
proxy_set_header Host $http_host;
proxy_read_timeout 36000s;
}

download, presentation and image upload

location ~ ^/(c|l)ool {
proxy_pass http_colon_slash_slash_10.187.15.197:9980;
proxy_set_header Host $http_host;
}

Admin Console websocket

location ^~ /cool/adminws {
proxy_pass http_colon_slash_slash_10.187.15.197:9980;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection “Upgrade”;
proxy_set_header Host $http_host;
proxy_read_timeout 36000s;
}
}

Trying to think this all the way through…

This is an imgur image of my network because I can’t seem to upload or link to an image.
https://i.imgur.com/ba7nv0C.png

welcome to the forum @HeneryH :handshake:

Take a look at this article and follow troubleshooting steps:

I’m not a pro with Apache config, from your description I don’t really get how Collabora is configured. but I’m missing (at least) ProxyPassReverse directive. Please review the config carefully. take a look at the docs as well:

https://sdk.collaboraonline.com/docs/installation/Proxy_settings.html

I don’t think (think) that Nginx has the concept of reverse.

I’m sorry I missed you are using Nginx…
but Nextcloud Collabora integration likely shows you the fault :wink:

I think my problem is in the area of your wiki drawing here

{argh, I can’t embed images}

sorry

https://i.imgur.com/yGzdxMY.png

Whenever I have collabora and nextcloud interact with each other via domain name, they go out to the local home router to resolve and come back in through the reverse proxy as shown in the image in the link.

I think this is what is messing with me.

I’m confused by this statement

don’t use internal names or IPs e.g. http://127.0.0.1, http://office:9980, http://192.168.0.7:80

If I don’t use hostnames or ip addresses then what is left?

Here is the interaction diagram with the reverse proxy that I need to figure out. And mine is nginx.

https://i.imgur.com/LcMxjlk.png

Doing the checklist, the results look good.

From the unified nextcloud/collabora server:

me@nextcloud:~$ curl --http1.1 https://nextcloud.my_domain.org/status.php
{“installed”:true,“maintenance”:false,“needsDbUpgrade”:false,“version”:“25.0.3.2”,“versionstring”:“25.0.3”,“edition”:“”,“productname”:“Nextcloud”,“extendedSupport”:false}

me@nextcloud:~$

me@nextcloud:~$ curl --http1.1 https://collabora.my_domain.org/hosting/discovery

    <!-- Writer documents -->
    <app favIconUrl="https://collabora.my_domain.org/browser/6fe6d24/images/x-office-document.svg" name="writer">
        <action default="true" ext="sxw" name="view" urlsrc="https://collabora.my_domain.org/browser/6fe6d24/cool.html?"/>
        <action default="true" ext="odt" name="edit" urlsrc="https://collabora.my_domain.org/browser/6fe6d24/cool.html?"/>
        <action default="true" ext="fodt" name="edit" urlsrc="https://collabora.my_domain.org/browser/6fe6d24/cool.html?"/>
        <!-- Text template documents -->
        <action default="true" ext="stw" name="view" urlsrc="https://collabora.my_domain.org/browser/6fe6d24/cool.html?"/>
        <action default="true" ext="ott" name="view" urlsrc="https://collabora.my_domain.org/browser/6fe6d24/cool.html?"/>
        <!-- MS Word -->

And from my home 192.x.x.x domain which emulates the WAN.

❯ curl --http1.1 https://nextcloud.warrinmy_domaingtonpatriots.org/status.php
{"installed":true,"maintenance":false,"needsDbUpgrade":false,"version":"25.0.3.2","versionstring":"25.0.3","edition":"","productname":"Nextcloud","extendedSupport":false}%


❯ curl --http1.1 https://collabora.my_domain.org/hosting/discovery
<wopi-discovery>
    <net-zone name="external-http">

        <!-- Writer documents -->
        <app favIconUrl="https://collabora.my_domain.org/browser/6fe6d24/images/x-office-document.svg" name="writer">
            <action default="true" ext="sxw" name="view" urlsrc="https://collabora.my_domain.org/browser/6fe6d24/cool.html?"/>
            <action default="true" ext="odt" name="edit" urlsrc="https://collabora.my_domain.org/browser/6fe6d24/cool.html?"/>
            <action default="true" ext="fodt" name="edit" urlsrc="https://collabora.my_domain.org/browser/6fe6d24/cool.html?"/>
            <!-- Text template documents -->

looks like you meet all the prerequisites, continue troubleshooting with application and browser logs (F12). For every browser request review reverse proxy and application logs if this arrives (in the expected place) and how the application reacts to it…

  • did you configure Collabora server with public fqdn in Nextcloud Office settings?
  • did you make Collabora aware of it’s public domain?
    – verify in the /hosting/discovery output - you should see your Collabora public domain everywhere in the XML

Just for reference and future readers:

means “don’t use internal hostnames” but always use public domains

Chasing down other potential problem due to running in an LXD/LXC env. Thanks.

This is probably a conflict between nextcloud collabora integration design and routing. If you are running both nextcloud and collabora under the same public IP, probably you have assigned them two different domain names (eg: nextcloud.example.com and collabora.example.com under 76.54.32.10). This will be common if you run both at home, in the same kubernetes cluster or behind the same reverse proxy.
In these situations, commonly nextcloud cannot route traffic to collabora (or viceversa) as the DNS resolution points to its own public IP.
Still looking for a solution…

I’m successfully running 2 Nextcloud instances and one Collabora with different publich hostnames nc.mycloud.tld, dev-nc.mycloud.tld, collabora.mycloud.tld on a single IP (docker containers on same server) behind traefik starting with NC version 19. I had some issues to fight with resulted bugs but most issues where related to configuration e.g. wrong DNS resolution inside docker… if you carefully configure your system everything works in such setup.

I fixed my problem. Being generous to myself, the root cause was a poorly worded exception/error message from the system.

I mistakenly entered an incorrect WOPI Allow List and the system was erroring out on me. I wish the error message had been clearer that it was denied by permissions or similar.

1 Like

congrats! may you could provide details on the error and post the logs for the reference?