Built-in CODE server issue with rendering the page during document opening

ℹ️ Support 📄 Office
, , ,
1

Hello, running nextcloud 30.0.2 in Podman, running the nextcloud:30.0.2-apache image, (the podman/docker thing is new for me, I am used to running nextcloud on native installs) and all is running fine. I have had issues with multi domain wopi group access on my CODE server instance, so this instance of nextcloud I am using the built-in code server, as it seems to run pretty snappy and usually works fine. However on some web clients it will not load the page correctly, everything is magnified and the screen scrolls down to a white background with no content.

I checked the nextcloud log, and greped through some of the coolwsd.log files I could find, and it may be an issue with SSL. The nextcloud container is just listening on port 80, as it is behind a reverse proxy with TLS and a trusted cert. Here is the error that may be my clue:

richdocumentscode (proxy.php) error exit, PID: 63, Message: No content in reply from coolwsd. Is SSL enabled in error ?

Just in the off chance anyone else is crazy enough to run docker style containers, do we need the env option: “-e “extra_params=–o:ssl.enable=false”” to disable SSL? I have nextcloud configured for TLS behind the proxy.

Example:


php occ config:system:set trusted_domains 0 --value='localhost'
php occ config:system:set trusted_domains 1 --value="cloud.example.tld.com"
php occ config:system:set overwrite.cli.url --value="http://192.168.50.55"
php occ config:system:set overwriteprotocol --value="https"
php occ config:system:set trusted_proxies 0 --value=192.168.50.21
php occ config:system:set overwritehost --value="cloud.example.tld.com"
php occ config:system:set auth.bruteforce.protection.enabled --value="true"

so I would just assume the code config would be SSL enabled? There aren’t much for errors to go on, and not much in the console output either. Just an odd intermittent issue. The server has 4G of memory and plenty of disk space so nothing stupid like that. I will keep digging the logs for clues, nothing obvious like I have seen before yet.

I did not find a coolwsd.conf file under /etc/coolwsd to check, so I am not sure how code is configured in this image, As I said, this is just a test instance as I am new to the docker container style setup, so I may just be wasting my time, but so far everything runs quite well, just not sure how to configure the built-in code app.

Here is what I see in the php occ config:list;

        "richdocuments": {
            "disable_certificate_verification": "",
            "enabled": "yes",
            "installed_version": "8.5.3",
            "public_wopi_url": "https:\/\/cloud.example.tld.com",
            "types": "prevent_group_restriction",
            "wopi_allowlist": "192.168.50.0\/24",
            "wopi_url": "https:\/\/cloud.example.tld.com\/custom_apps\/richdocumentscode\/proxy.php?req="
        },
        "richdocumentscode": {
            "enabled": "yes",
            "installed_version": "24.4.1103",
            "types": ""
        },
2

Can you check the browser inspector when this happens? Specifically the Console and Network tabs. Is there any other pattern to the occurrences of this? As in:

  • Is it always the same clients?
  • Is it at any particular time or interval?
  • etc

do we need the env option: “-e “extra_params=–o:ssl.enable=false”” to disable SSL?

No. The Built-in edition of CODE essentially internally proxies between the richdocumentcode app’s proxy.php script and CODE itself. It’s not a traditional “CODE behind a reverse proxy” deployment.

You can maybe get some more logging if you uncomment line 24 here in your custom_apps/richdocumentscode/proxy.php file, but my guess is something else will be the culprit here.

The server has 4G of memory and plenty of disk space so nothing stupid like that.

Note that the Built-in edition runs from /tmp in the Docker image…

1 Like
3

Thanks jtr.
No pattern yet, is so far just random. I have watched the console output when I notice the issue, and I did see some ‘404 not found’ and mostly just a bunch of deprecation noise. Thanks for confirming the ssl.enable. The last time it popped up on my desktop (brave browser) I let the page refresh a couple of times and it just started rendering the page fine, with no errors in the console output. So strange, issue does not seem to show up when the instance is accessed from the web through the RP, I still need to do more testing. I can’t call it a regression, since everything works fine, it just freaks out at random times, but then will work fine.

4

by occasion I found this:

Gray document area, no document loaded

When you see gray document are, i.e. the iframe of Collabora Online is not loaded, you can check the browser‘s console to see what is going on. For the browser‘s diagnostic tools, press F12, and see network activity.

A common mistake, when http and https content is mixed on the same page, and the browser refuses to load insecure http iframe into an https page. If SSL is used, which is highly recommended, make sure that all components, including Collabora Online is set up for SSL.

The iframe can be blocked due to a content security policy setting. The problem should be reported on the browser‘s console. See Content Security Policy.

Gray screen could be the result of incorrectly set up reverse proxy (see below), and related server_name setting.

maybe it helps :wink:

1 Like
5

Thanks! Far as I can tell, the built-in CODE instance defaults to SSL - since I did not provide the ssl.enable=false setting. The container is behind an nginx reverse proxy with a trusted cert. So far I notice the issue goes away after refreshing the page a few times, then it works fine with no issues.

Crossing my fingers the nextcloud upgrade from 30.0.2 to 30.0.4 goes smooth, I understand I just need to stop the app container and pull the newer version and it should just startup and keep rolling along. Following the guide here: GitHub - nextcloud/docker: :ferry: Docker image of Nextcloud

6

I have the feeling you are not talking about collabora-built-in - this one has no config and runs behind “integrated Nexcloud reverse proxy” and has no idea of your nginx reverseproxy and your reverse proxy has no idea nor any special config - it collabora-built-in acts as part of Nextcloud application.

BTW: as long you use docker there is no value running collabora-built-in - separated container running “real” dedicated CODE collabora-online works better, is easier to configure and troubleshoot see How to configure collabora CODE with docker

1 Like
7

I will give it a try in a dedicated container and see how it runs. I have a native installed CODE server running on it’s own VM host, but was never successful in connecting my two nextcloud domains, it would only allow one or the other, so I will try it with the aliasgroup1/2 setup. Thanks!

8

So I tried spinning collabora up in it’s own container, and added it to the pod.

In the nextcloud UI I changed it to “use your own server” and entered in “https://CODE:9980” (container name is CODE) and it states the server is reachable when I click save.

However documents do not open. I gather since the collabora server is not reachable through the reverse proxy is the cause for documents failing to open. Does the collabora server need to be reachable from the web client for opening documents? On the production instance of collabora, I have it reachable through the reverse proxy direct, but can only access it from one domain, so is not an option for my other domain.

9

Ok figured it out, was an issue with the reverse proxy - did some troubleshooting and tested curl -k https://host_ip/hosting/discovery from the nextcloud instance, and the reverse proxy and determined the RP needed proxy_pass https://ip_of_code_server:9980;
and not proxy_pass http://ip_of_code_server:9980;

Once I was able to get curl -k to render the discovery page correctly, I am good to go on the dedicated collabora instance. SSL is terminated at the reverse proxy for both the nextcloud instance as well as collabora.

Now with the new collabora container behind the reverse proxy, I can reach it by it’s public fqdn from both the nextcloud instance and the client that connects through the reverse proxy from port 443 to 9980 and all seems to be working really well. Not sure if I can access this instance of collabora from my other domain, but I will test it.
Thanks for all the tips! Now I have the nextcloud stack on 2 domains, one is all native installed, and the other is all podman (docker) containers.