enable-encryption.bat screenshot (Windows)

odilon.properties

The next step is to edit the file odilon.properties:

				
# The encryption key is provided by Odilon when initializing the encryption service using the 
# enable-encryption.sh (Linux) or enable-encryption.bat (Windows) script.
encryption.enabled = true
encryption.key = ff67a066008a498fff6335bb1187a4d64db04c8c661caa38b1e1ae8d93c0915c796d5165c06f439b76ba20d3
				
				

and start Odilon normally.

The server will print Encryption enabled -> true on startup.

Enabling encryption only affects objects uploaded from that moment on. Objects that were already stored before the encryption service was initialized and enabled remain unencrypted on disk.

To encrypt them, Odilon provides an asynchronous administrative process that walks through all the buckets and re-stores every unencrypted object through the regular update path. It runs in the background while the server keeps serving requests normally.

Prerequisites

The encryption service must be initialized (see above) and enabled (encryption.enabled = true in odilon.properties), and the server must be running.

The data storage must be writable: the process is rejected if dataStorage.mode is readonly or worm.

Only one encryption process can run at a time.

Start the process

Call the endpoint POST /encryption/encrypt with the server credentials. Optionally restrict the process to a single bucket with the bucket parameter.

				# all buckets
curl -X POST -u odilon:odilon "http://localhost:9234/encryption/encrypt"

# only one bucket
curl -X POST -u odilon:odilon "http://localhost:9234/encryption/encrypt?bucket=documents"
				
				

The call returns immediately with HTTP 202 Accepted:

				{"result":"encryption started"}
				
				

If a process is already running the server answers HTTP 409 Conflict. If encryption is not enabled or not initialized, or the data storage is read only / WORM, the request is rejected with HTTP 405 Method Not Allowed.

Monitor progress

Call GET /encryption/status to follow the current run (or inspect the result of the last one):

				curl -u odilon:odilon "http://localhost:9234/encryption/status"
				
				

				{
  "status": "RUNNING",
  "bucket": null,
  "currentBucket": "photos",
  "started": "2026-10-09T14:21:05.117Z",
  "finished": null,
  "threads": 4,
  "scanned": 12850,
  "encrypted": 9311,
  "skipped": 3539,
  "notAvailable": 0,
  "errors": 0,
  "totalBytes": 48123456789,
  "durationMillis": 184203,
  "message": null
}
				
				

• status: IDLE, RUNNING, COMPLETED or FAILED
  (FAILED means the run finished but at least one object could not be encrypted, see errors).
• scanned: objects listed so far.
• encrypted: objects that were re-stored encrypted.
• skipped: objects that were already encrypted.
• notAvailable: objects listed but deleted or not readable when they were processed.
• errors: objects that failed, details are in the server log.
• totalBytes: plaintext bytes processed.

A summary is also printed in the server log when the process finishes.

How it works

Each unencrypted object is re-stored through the normal object update, so the result is identical to a client uploading the same file again: the RAID driver, journal, caches and search index are all updated consistently.

If Version Control is enabled, the update creates a new (encrypted) version. The previous version remains stored unencrypted. Use the regular version-cleanup operations to remove old versions if required.

Objects created or updated by clients after the process started are already encrypted and are simply skipped. Each object is checked again under lock right before being re-stored, so a concurrent client update is never overwritten with old data.

The process is idempotent: it can be executed as many times as needed. If the server is stopped while it is running, just start it again; objects already encrypted are skipped.

Errors on individual objects are logged and counted, they do not stop the run.

IMPORTANT

Re-storing objects requires free disk space: while an object is being processed a temporary plaintext copy is created, and with Version Control enabled the unencrypted previous version is kept. Make sure there is enough space before running the process on large repositories.

In case the encryption key is compromised or lost it is possible to generate a new encryption key.
To generate a new encryption key You will need the server's master key, just execute the script (in ./bin directory):

Windows
rekey-encryption.bat -m masterkey

Linux
sudo /opt/odilon/bin/rekey-encryption.sh -m masterkey

Example (Windows):

				.\rekey-encryption.bat -m 946529d6c7cce1a37af1c48e780dbaf11f3d9be7aaee52d09de8c0ac42a0dac5
				
				

IMPORTANT

If you lose the master key you will not be able to generate a new encryption key.