Nextcloud Encryption at Rest: What It Protects, and What It Does Not

The question behind this search is almost always the same one: if someone gets to my Nextcloud data, does this setting stop them?

The answer depends entirely on which someone, and the feature is far more useful against one of them than the other.

What it encrypts, and what stays readable

Nextcloud's server-side encryption app encrypts the contents of files. That is a real protection and it works.

What it does not cover is the part people assume comes with it:

• Filenames stay readable.
• Folder structure stays readable.
• File sizes and modification times stay readable.

A directory tree of named documents describes a great deal about their contents without opening a single one. clients/acme/termination-letter-final.docx tells you the story; the ciphertext inside adds detail you had already guessed.

This is not a flaw in the implementation. It is a consequence of encrypting at the file-content layer while the server still needs to list, sort and serve those files. It just needs to be known before you rely on it.

The fact that decides everything: where the keys live

In a standard single-server installation, the encryption keys are stored on the same server as the encrypted data.

Take a moment with that, because every sensible conclusion follows from it.

It defeats the adversary who gets the storage without the server. A decommissioned disk sold on. A backup volume that ends up somewhere it should not. And, most commonly for self-hosters, an external storage backend: object storage or a rented storage box attached to your instance. The provider holding those bytes cannot read them. This is why the search for this topic so often arrives with a hosting provider's name attached to it, and in that scenario the feature does exactly what people hope.

It does not defeat the adversary who gets the server. Someone with root on the machine has the data and the keys in the same place. The same is true of a running instance compromised through the application. Encryption at rest is not a defence against a live compromise, and treating it as one is the mistake worth avoiding.

A useful way to phrase it: at-rest encryption protects data from whoever holds the disks. It does not protect data from whoever runs the server.

Master key or per-user keys, and why the recovery key exists

These are not two quality levels of the same option. They are two different trade-offs.

Master key mode keeps a single key that the instance can use to decrypt everything. The instance stays administrable, password resets are harmless, and nothing is lost when a user leaves. The cost is that a single point can decrypt all of it, and whoever controls the server controls that point.

Per-user key mode derives each user's key material from their password. An administrator can no longer trivially read a user's files, which is a genuine gain if the administrator is part of your threat model.

And here is where instances lose data. If a user's password is reset by an administrator, the material derived from the old password is gone, and so is access to their files. The recovery key exists precisely for this, and it has to be enabled before the incident. Turning it on after a password reset does not bring the old files back.

⚠️ Decide this before you have users, not after. Migrating between the two modes on a populated instance is the kind of operation that goes wrong quietly, and the failure mode is unreadable files rather than an error message.

If the server operator is your threat model

Then at-rest encryption is answering a question you did not ask, and you want encryption that happens before the data reaches the server.

That is a different mechanism with different trade-offs, and our page on client-side encryption covers what it buys and what it costs, including the features you give up when the server can no longer read anything.

The distinction between that and various marketing uses of "encrypted" is worth having straight as well, which is what end-to-end versus zero-knowledge sets out.

What it costs you

Performance. Every read and write passes through encryption, and the effect is most visible on many small files rather than on a few large ones.

Operational fragility. Encrypted data plus lost or corrupted keys equals unrecoverable data, and no support channel changes that. Your key material now needs a backup strategy of its own, kept separately from the data it unlocks. A backup that contains both is a backup of a solved puzzle.

Feature friction. Some server-side operations become more awkward once the server handles ciphertext, and this is worth testing on your own workflow before enabling it on a live instance.

We publish no percentage for the performance cost. It depends on your hardware, your storage backend and your file mix, and a figure taken on one instance misleads on another. Time your own before and after, with the same files and the same client.

The short version

• It encrypts file contents. Filenames, folder structure and sizes stay readable.
• In a standard setup the keys sit on the same server as the data, which is the whole story.
• It defeats whoever holds the disks, including an external storage backend. It does not defeat whoever runs the server.
• Master key keeps the instance recoverable; per-user keys resist the administrator. Different trade-offs, not better and worse.
• Enable the recovery key before you need it. After a password reset is too late.
• If your adversary is the server operator, you want encryption that happens before the upload.

This page describes the documented behaviour of Nextcloud's server-side encryption feature and the consequences of where key material is stored. It gives no performance figure because that depends on hardware and workload. Commercial links carry the rel="sponsored nofollow" attribute; an affiliate commission may apply at no extra cost to you.