Fix CODE’s WOPI Host Check by Matching the Host Origin

When Collabora Online CODE reports “Unauthorized WOPI host,” add the actual file-storage host—usually your Nextcloud origin—to CODE’s WOPI host allow-list. The host must match the origin CODE receives in the WOPI request, not the public URL of the Collabora server. In Docker, that is commonly configured with the aliasgroup1 environment variable.

What CODE is rejecting

WOPI means Web Application Open Platform Interface, the protocol an office server uses to open and save files through a storage platform. The WOPI host is that storage platform, such as Nextcloud. CODE checks the host named in the WOPI request against the hosts it trusts. If the request names cloud.example.com but CODE is configured to trust only office.example.com, the editor can refuse the session before it opens.

For a self-hosted setup, the hostname in the request may be an internal Docker name such as nextcloud rather than the browser-facing hostname. A reverse proxy, a different port, or separate public and internal URLs can also make the origin differ. Configure what the request actually uses, not what seems like the “main” server name.

Find the host CODE is rejecting

1. Reproduce the failure once, then inspect the CODE container log around that time. With Docker Compose, run docker compose logs --since=10m collabora, replacing collabora with your service name.
2. Look for a message such as No acceptable WOPI hosts found matching the target host [cloud.example.com] in config. Record the target host shown in brackets. Do not copy or share a full WOPI URL: it can contain a short-lived access token.
3. Compare that hostname and scheme with the URL your storage integration advertises to CODE. In Nextcloud, its troubleshooting guidance recommends checking that the configured URL is the Nextcloud URL and that CODE can reach it. Check the WOPISrc host, if available in your integration logs, while keeping any query-string token private.

Allow the correct origin in CODE

For the official CODE Docker image, set aliasgroup1 to the exact trusted WOPI origin. For a single Nextcloud installation, a Compose service can include:

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

Replace the example with your real Nextcloud host and the scheme and port that the WOPI request uses. Keep the existing image tag, administrator settings, network, and other service options in your Compose file. The example uses an HTTPS origin with port 443; a different deployment may use another port or an internal origin.

After editing the Compose file, recreate the CODE container so it receives the updated environment:

docker compose up -d --force-recreate collabora

Use your actual Compose service name in place of collabora. A plain restart may not load changed container environment values; recreating the service applies the updated configuration. If you configure CODE through its XML file, check the storage.wopi alias groups in the effective configuration instead. The official Collabora SDK manual documents Docker alias groups and WOPI host aliases; follow the syntax for the CODE version you run.

Keep the two allow-lists separate

Collabora and Nextcloud can each enforce a WOPI-related restriction, but they answer different questions:

Changing Nextcloud’s source-IP allow-list will not correct CODE rejecting a hostname. Conversely, adding a hostname to CODE does not authorize CODE’s source IP at Nextcloud. Nextcloud’s documentation recommends restricting WOPI requests to the Collabora server’s IP addresses; use the address observed by Nextcloud, which can differ when containers or a reverse proxy are involved.

Quick checks before closing the incident

• Target says cloud.example.com: allow that Nextcloud host and the appropriate origin in CODE.
• Target says nextcloud: CODE is probably receiving a Docker-network hostname; decide whether that internal origin is intended, then configure the corresponding trusted host and ensure DNS/network reachability.
• Target matches, but the same rejection remains: confirm that the edited variable belongs to the running CODE service, that Compose recreated the container, and that no later environment or XML configuration overrides the setting.
• The log changes to a DNS, TLS, timeout, or CheckFileInfo failure: the host authorization check may now be passing. Investigate name resolution, certificate trust, routing, or the storage integration’s file-info response instead of broadening the WOPI host list.
• Nextcloud reports an unauthorized request address: review Nextcloud’s source-IP allow-list and the client IP it actually sees.

Do not solve a mismatch by trusting every host or using an unrestricted wildcard in a production deployment. Keep the allow-list limited to known storage origins. If multiple storage hosts are intentional, configure the documented alias groups for your installed CODE version rather than guessing at wildcard behavior.

Verify the fix

Open a document through the same Nextcloud integration that failed. Then check fresh CODE logs: the “No acceptable WOPI hosts” rejection should be gone. Confirm that the document loads and can be saved; if a new error appears, use its message to identify the next layer. For the two host checks and the Nextcloud troubleshooting flow, consult Nextcloud Office troubleshooting and Nextcloud Office configuration. For CODE Docker alias groups, see the Collabora Online SDK 25.04 manual; use the documentation matching your installed release if its configuration differs.