Fix the “Unauthorized WOPI Host” Error in Collabora Online CODE

The fastest reliable fix is to make Collabora Online CODE trust the exact hostname and port that appear in the WOPI source URL sent by your storage platform. For a single Nextcloud server, set the CODE host allow-list to that Nextcloud hostname, recreate the container, and test again. If you operate multiple Nextcloud instances, allow each one explicitly. Do not solve the error by opening WOPI access to every host.

“Unauthorized WOPI host” usually means Collabora rejected the storage host named in the WOPI request. It does not, by itself, prove that the user’s password, document permissions, TLS certificate, or reverse proxy is wrong. Those components can cause other connection failures, so use the Collabora logs to confirm the specific cause before changing settings.

Choose the change that matches your deployment

The examples below assume Nextcloud at https://cloud.example.com and Collabora at https://office.example.com. Replace both names and the port with the values used in your installation. Nextcloud’s Docker setup guide uses aliasgroup1 for a single storage host and describes adding another alias group for a second Nextcloud host. Collabora’s WOPI configuration defines host matching around the hostname and port; aliases are for alternate names of the same storage host.

1. Confirm which host Collabora rejected

Start with the CODE container logs. On a Docker Compose deployment, run:

docker compose logs --since=10m collabora

Replace collabora with the service name in your Compose file. With plain Docker, use docker logs --since 10m CONTAINER_NAME. Look near the failed document-open attempt for a message such as No acceptable WOPI hosts found matching the target host [cloud.example.com] in config. The bracketed hostname is the clue: add the storage host shown there, not the public hostname of the Collabora server.

Also record the host and port in the WOPI URL, if shown in the log. Compare them with the configured entry. A request to cloud.example.com:443 may not match an entry for an internal container name such as nextcloud, even if both names resolve to the same machine. Reverse proxies, split-horizon DNS, and multiple public URLs can make this mismatch easy to miss.

If the logs show a different error, such as a DNS lookup failure, a refused connection, or a certificate error, fix that issue instead of broadening the WOPI host list.

2. Update CODE’s trusted WOPI host setting

For a Docker Compose installation serving one Nextcloud host, the relevant part of the service can look like this:

services:
  collabora:
    image: collabora/code
    environment:
      - aliasgroup1=https://cloud.example.com:443

Keep the rest of your existing service options, secrets, volumes, ports, and reverse-proxy settings. The example shows the allow-list entry only; it is not a complete production Compose file. Use the setting style already supported by the CODE version you run, and check the rendered or startup configuration after changing it. Container images and configuration interfaces can change over time.

For a single host, an exact host entry is easier to audit than a broad regular expression. If your installation relies on the domain environment variable instead, verify the escaping rules documented for your image and make sure the expression matches only the intended storage hostname. Do not copy an unescaped wildcard or a parent-domain pattern that would match unrelated subdomains.

For more than one Nextcloud instance, add a separate explicit group for each independent host using the mechanism supported by your CODE release. For example, Nextcloud’s Docker integration guide shows an additional aliasgroup2 entry for a second cloud hostname. Add aliases only when one Nextcloud server is genuinely reached under multiple names, such as an internal name and a public name. Keep a written list of those names so an old hostname can be removed after a migration.

3. Recreate the container and check Nextcloud’s separate allow-list

After editing the Compose file, recreate the service so the new environment is applied:

docker compose up -d --force-recreate collabora

Use the correct service name. Then check that the container starts cleanly and that the expected host appears in its startup configuration or logs. Avoid pasting full environment dumps into support requests: they can expose passwords or other secrets.

Nextcloud has a separate setting called “Allow list for WOPI requests” under its Office administration settings. This list restricts which IP addresses may make WOPI requests to Nextcloud; Collabora recommends limiting it to the expected Collabora server addresses. If Nextcloud reports this warning, add the address that Nextcloud actually sees for the request, which can differ when a proxy or container network is involved. Keep this check distinct from the CODE host entry: CODE trusts storage hostnames, while Nextcloud’s allow-list concerns the requesting server IP.

If you use a reverse proxy, confirm that the hostname Nextcloud publishes in WOPI links is the same hostname CODE is configured to trust. Check the Nextcloud Office server URL and the reverse proxy’s public host configuration. Do not add the office hostname to the WOPI storage allow-list unless it is actually the storage host in the WOPI URL.

4. Verify the complete connection

First, check the Collabora service endpoints from a browser and from the Nextcloud server. Replace the example hostname with your Office URL:

curl -fsS https://office.example.com/hosting/capabilities
curl -fsS https://office.example.com/hosting/discovery

These checks establish that the endpoints respond; they do not prove that a WOPI document request will be authorized. Next, verify that CODE can reach Nextcloud using the same host Nextcloud publishes, for example:

curl -fsS https://cloud.example.com/status.php

Finally, open a test document and watch the CODE and Nextcloud logs at the same time. A successful result is that the editor loads, the specific “No acceptable WOPI hosts” message is gone, and saving a small change works. Test from a normal user account with the same sharing and editing permissions as the affected user.

How the main options compare

One exact host versus a regular expression

An exact hostname with the intended port is usually the best fit for a single-cloud deployment: it is easy to review and limits accidental matches. A regular expression can help when a deliberately managed set of hostnames shares a pattern, but it is harder to audit and can authorize unintended subdomains if written too broadly. Use the narrowest expression that satisfies a verified need.

One CODE instance versus separate instances

A shared CODE service reduces the number of services to maintain, and explicit groups can support multiple Nextcloud instances. Separate CODE instances can make sense when teams need stronger configuration isolation or independent maintenance windows. The trade-off is more infrastructure to patch, monitor, and route. Neither option fixes a mismatched WOPI hostname automatically; each instance must trust the right storage host.

Container environment settings versus editing XML

For a Docker CODE deployment, use the configuration interface supported by the image and keep it in Compose or another deployment source of truth. This makes changes repeatable when the container is recreated. Editing coolwsd.xml directly can be useful for a managed package or a deliberate custom deployment, but editing a generated file inside a running container is fragile and may disappear on replacement or upgrade. Follow the instructions for the exact package, Helm chart, or image you use.

Common mistakes to avoid

• Allowing office.example.com when the rejected WOPI storage host is cloud.example.com.
• Entering a private container name when the WOPI URL contains a public DNS name, or vice versa.
• Assuming that a blank Nextcloud WOPI IP allow-list and CODE’s host configuration are the same control.
• Adding a broad wildcard or disabling host validation just to make the editor load.
• Changing the proxy, TLS, and WOPI rules at once, which makes the result harder to diagnose.
• Testing only the discovery endpoint and treating it as proof that document authorization works.

When to use a different fix

If the rejected host changes between requests, inspect the canonical Nextcloud URL, trusted proxy headers, and any alternate webroots before adding more names. If all hostnames match but the error persists, compare the active CODE configuration with the file or environment settings you edited and confirm the container was recreated. For Kubernetes or Helm, edit the chart values or managed configuration source rather than a live pod. If logs show certificate, firewall, WebSocket, or DNS errors instead, troubleshoot that layer using the appropriate server logs and network checks.

These steps follow the Nextcloud 35 Administration Manual available on October 6, 2026, and Collabora’s published WOPI configuration schema. Specific configuration keys can vary by deployment method and image version, so verify them against the documentation for your installed release before applying a change.

Official references

• Nextcloud Office troubleshooting and connectivity checks
• Nextcloud’s Docker example for Collabora, including WOPI host settings
• Nextcloud Office configuration and WOPI IP allow-list guidance
• Collabora Online’s published coolwsd.xml configuration schema
• Collabora Online proxy settings documentation