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