Block File Exports in Collabora CODE Through WOPI

To prevent users from exporting an open document in Collabora Online CODE, have your WOPI host return "DisableExport": true in that document’s CheckFileInfo response. Collabora’s integration documentation describes this as disabling export functionality; when set, the Download as menu option is hidden too. HideExportOption alone only changes the interface, so it is not the right control when the goal is to prohibit exporting. See Collabora’s extended CheckFileInfo response properties.

Use the WOPI permission, not a menu-only setting

CODE is the editing component in a WOPI integration. Your storage or application service acts as the WOPI host and supplies per-file information when Collabora opens a document. That makes the host the appropriate place to decide whether a particular user may export a particular file.

In the JSON object returned by the host’s CheckFileInfo endpoint, include the boolean property:

{
  "BaseFileName": "quarterly-plan.docx",
  "Size": 24576,
  "UserCanWrite": true,
  "DisableExport": true
}

This is an illustrative fragment, not a complete CheckFileInfo response. Keep the other required fields and any existing integration properties your host already returns. The key value must be a JSON boolean, not the text string "true". Set it using the same authorization decision your application uses for the file and current user.

For example, an organization might let staff edit a confidential budget workbook while preventing them from using Collabora’s export functions. When the WOPI host opens that workbook for a staff member, it returns DisableExport: true. For a public template or an ordinary document, the host can return false according to its policy. A static value applied to every document is appropriate only if every user and document should receive the same restriction.

Update the WOPI host that serves the file

1. Identify the integration endpoint. Find the host route that answers Collabora’s WOPI CheckFileInfo request for the file. In Nextcloud, ownCloud, or another storage product, this normally means changing the integration or policy layer that generates the response; editing the Collabora container’s global configuration is not a substitute for the host’s per-file permission.
2. Apply the rule at the right scope. Derive the value from the authenticated user, file classification, share permissions, or another rule in your application. For a simple all-users policy, return true for every relevant document. Avoid relying on a browser-side menu preference or a client-supplied value.
3. Return the boolean in CheckFileInfo. Ensure the response is valid JSON and includes the property in the response Collabora receives. A code-level policy change may require deploying or restarting the WOPI host application, depending on its framework; CODE itself may not need a configuration change when the host dynamically supplies the field.
4. Reopen the document. Close the current editor session and open the file again under the affected account. CheckFileInfo is consulted as part of the document-opening flow, so an already-open session may not reflect a changed permission.

The exact file, class, setting, or administrative interface varies by WOPI host and product version. Collabora’s documentation defines the field, but it does not prescribe a universal Nextcloud or third-party application setting. If your host does not expose a download restriction, check that product’s current administration documentation or implement the policy in its supported WOPI response path.

When should you also set HideExportOption?

Set HideExportOption to true when you want the Download as control hidden without enforcing the export prohibition. For an actual restriction, prefer DisableExport: true; Collabora’s integration guide says that this also implies the menu-hiding behavior. Returning both fields as true can make the intention explicit in an integration, but it should not be necessary for the documented behavior.

Do not confuse this with the extra_export_formats entries in coolwsd.xml. Collabora’s current configuration template explicitly says that disabling those optional formats only hides them visually and does not disable server-side exporting. Those options control which extra formats are offered, not whether a user is authorized to export a document. Review the current Collabora Online configuration template before changing global settings.

What this restriction does—and does not—protect

DisableExport applies to Collabora’s export functionality for the session. It is useful when users should edit a file in the browser but should not use the editor’s export or Download as features. It does not by itself remove the user’s access to the original file in the storage service. If the host still lets that user download the source file elsewhere, the Collabora setting does not close that path.

Likewise, a user who can view content may be able to copy information manually, take screenshots, or use other application features that your policy permits. Do not describe this setting as preventing all data exfiltration or guaranteeing that content cannot be copied. To limit access to the original, enforce download and sharing rules in the WOPI host and storage application as well. If your requirement is that a user must not see the content at all, deny document access rather than relying on an export flag.

There is also a distinction between hiding an interface item and disabling an operation. Collabora’s configuration template makes that distinction for its optional export-format settings, while the WOPI response field is the integration-level restriction. The first action is useful for simplifying menus; the second is the setting intended to block exports through Collabora. If an existing integration behaves differently, verify its Collabora release and inspect the actual CheckFileInfo response rather than assuming a particular host product maps its own “disable download” checkbox to both fields.

Verify the restriction with a test account

1. Use a non-administrator account that matches the restriction policy and open a test document in a fresh session.
2. Confirm that the editor’s Download as option is no longer available. If it still appears, inspect the CheckFileInfo response produced for this exact user and file; confirm the field is boolean true and that the new response is being served.
3. Test the export action through the normal Collabora interface. The host’s policy should be reflected in the editor behavior. Do not conclude that the control is enforced merely because the menu item is hidden.
4. Check the storage application separately: try its own download route only if your test plan permits. A successful download there means the source-file access policy still allows it, even if Collabora blocks exports.
5. Open a document for a user who is allowed to export and confirm that your host returns the intended permission for that case. This catches rules that were applied globally by mistake.

For implementation details, use Collabora’s WOPI integration reference and the project configuration template. CODE’s supported behavior can vary across releases and host integrations, so validate the response and result on the version you deploy. No claim is made here that a particular host version or sample deployment was tested.