Protect Collabora CODE Documents at Rest with Storage Encryption

To encrypt documents at rest when using Collabora Online Development Edition (CODE), enable encryption in the file-storage platform or on the underlying disk—not in the CODE editor. Collabora opens documents supplied by a WOPI storage host, while the host is responsible for keeping the saved copies protected. The result should be encrypted storage, working edits, and recoverable files.

Identify which system actually stores the files

A typical deployment uses Nextcloud or another WOPI-compatible service for file storage and CODE for browser-based editing. A document moves between those components during an authorized editing session; turning on HTTPS protects that connection but does not encrypt the stored copy. Collabora's security overview describes storage as integration-controlled, while its server configuration template documents WOPI, TLS, and optional cache and quarantine settings.

Before changing anything, record where the WOPI host writes document files, whether it uses local disks or external object storage, and where CODE itself runs. Include backups, snapshots, previews, swap, and container volumes: copies outside the main directory may remain unprotected.

Choose encryption that matches the risk

For documents on a Linux server's local disk, disk or volume encryption such as LUKS is usually the straightforward option. It protects the underlying storage when the volume is locked, including against theft of a powered-off drive. Ubuntu's full-disk encryption documentation describes LUKS as block-level encryption, not an application setting. Use a new encrypted volume or a tested migration: initializing LUKS can destroy existing data.

If Nextcloud stores files on third-party storage and the storage provider must not read their contents, Nextcloud server-side encryption (SSE) may be a better fit. It encrypts supported file contents before saving them to backend storage. Its keys remain in Nextcloud, so a compromised server or administrator can access decrypted files. Nextcloud recommends considering disk encryption for local storage.

If even the application administrator must be unable to read a document, neither unlocked-disk encryption nor ordinary SSE meets that requirement. Evaluate a supported client-side or end-to-end encryption workflow and confirm that browser editing remains available; do not presume every encrypted document can be opened collaboratively in CODE.

Enable encryption on the storage host

Option A: Encrypt the local volume

For a new Linux deployment, provision the file data and relevant service volumes on encrypted storage before importing documents. Keep the unlock secret and recovery information outside the server, restrict administrative access, and test the reboot or unlock procedure. For existing systems, verify backups and migrate during downtime. Configure encryption for cloud volumes or object storage with the provider.

Use lsblk -f to identify block-device types and findmnt -T /path/to/document/data to identify the filesystem backing your actual data directory. Check the path from the data directory to the encrypted device: installing cryptsetup alone does not encrypt a filesystem.

Option B: Enable Nextcloud server-side encryption

When Nextcloud SSE is appropriate, follow its server-side encryption guide. Back up the Nextcloud configuration, database, files, and encryption keys before making changes. Decide on the key mode before encrypting content; the current guide describes a server-controlled master key as the default for most deployments.

1. Enable the Nextcloud Default Encryption Module in Apps, then enable server-side encryption in administration settings, or use the documented occ commands.
2. On a conventional Linux installation, run commands from the Nextcloud installation directory as the web-server account: sudo -E -u www-data php occ app:enable encryption, then sudo -E -u www-data php occ encryption:enable. Adapt the user and execution method to your packaging; Docker deployments use commands inside the appropriate container.
3. Run sudo -E -u www-data php occ encryption:status to confirm the feature and selected module. Do not interpret an enabled flag as proof that every preexisting file is encrypted.
4. Schedule a maintenance window without user file access and run sudo -E -u www-data php occ encryption:encrypt-all to address preexisting files. This operation can take time, and the official encryption command reference notes that it manages maintenance mode and requires an interactive terminal.

SSE excludes filenames, folders, existing trash files, some old versions, thumbnails, previews, search indexes, and certain application data. Protect excluded items separately if required. Protect backups of encryption keys; losing essential keys or instance secrets can permanently prevent recovery.

Protect CODE's host and keep the editing path secure

Even when the WOPI host encrypts stored documents, assess the CODE machine independently. Collabora describes active document handling as memory-oriented and does not position CODE as the permanent document repository. However, the published coolwsd.xml template includes settings for optional quarantine and cached files, so inspect the actual deployment rather than assuming every temporary artifact is absent. Cover container runtime storage, mounted volumes, system swap, crash dumps, and backups with appropriate encryption or retention controls.

Keep HTTPS between browsers, CODE, and the WOPI service, and restrict which WOPI hosts can connect. Nextcloud's Office configuration documentation recommends limiting WOPI requests to expected Collabora server IP addresses. These access controls do not replace at-rest encryption, but they help prevent the encrypted storage system from handing plaintext to an unauthorized editor.

Do not enable Collabora's local filesystem storage mode for production as a shortcut; its official SDK describes filesystem storage as a testing-only option and recommends WOPI. Keep the normal storage integration in place so authorization and save-back behavior remain consistent.

Check whether the result is good enough

Use a non-sensitive sample file for the acceptance test. Upload it through the storage service, open it in CODE, edit a line, save, close the editor, and reopen it. A successful round-trip confirms editing still works; it does not prove at-rest encryption.

• Storage proof: verify that the actual document directory resolves to the intended encrypted volume, or that the storage service reports the expected encryption configuration. For SSE, check whether data held by the backend is unreadable without the storage application's keys, using a controlled test and authorized backend access.
• Old-file coverage: confirm migration or encryption:encrypt-all completed successfully; do not test only a newly uploaded file.
• Secondary copies: check backups, snapshots, preview data, logs, and CODE host storage against the same protection requirement.
• Recoverability: restore a sample and its needed keys in a separate test environment, then confirm that the document opens and saves through CODE.

Switch approaches if the storage provider or application must be unable to decrypt contents, if a protected data category remains outside the encryption boundary, or if key recovery cannot be demonstrated. Encryption at rest mainly limits exposure from storage loss and unauthorized backend reads; it cannot by itself stop a compromised live server, an authorized user downloading a file, or a stolen account from reading an opened document.