Cryptomator turns a folder in local or cloud-synchronized storage into an encrypted vault. It encrypts file contents, names and directory structure inside that folder. When the user unlocks the vault, Cryptomator exposes a virtual drive with readable files. The cloud provider sees encrypted objects; it does not receive the vault password or the normal file names through Cryptomator.
The encrypted folder and virtual drive are different views
A new vault can live inside a folder already synchronized by a cloud client. Adding an existing vault begins by locating its masterkey file. The encrypted directory should remain under the synchronization service, while normal editing happens through the unlocked virtual drive.
Locate Encrypted File maps a visible item to its encrypted storage representation, and Decrypt File Name performs the reverse mapping for a supported name. Editing ciphertext files or renaming encrypted directories outside Cryptomator can break the internal relationships that the virtual view needs.
The recovery key is the password reset path
Cryptomator can generate a recovery key that resets a forgotten vault password. Cryptomator does not store that recovery key and cannot perform the reset without it. Keeping it only inside the vault creates a circular recovery problem because the user needs the vault password to read it.
Changing a vault password changes the key-encryption key rather than re-encrypting every stored file. This makes the change quick, but it also means that a versioned cloud service may retain an older masterkey file protected by the former password. Replacing a weak password does not rewrite every historical cloud version.
The volume backend changes filesystem limits
Cryptomator can expose a vault through WinFsp, macFUSE or FUSE. WebDAV remains a loopback fallback. On Windows, the WebDAV backend has a four-gigabyte file limit, a legacy path-length limit and unreliable free-space reporting. The documentation recommends WinFsp instead when it is available.
A file that fails through WebDAV may not be corrupt in encrypted storage; it may exceed the mounted backend’s limit. Changing the volume type affects the decrypted access path, not the ciphertext already synchronized in the vault directory.
Configuration recovery cannot recreate deleted ciphertext
Vault recovery can rebuild missing configuration information when encrypted files still exist. It cannot recover an encrypted file that storage or synchronization already deleted. Cloud version history may supply an earlier ciphertext object, but Cryptomator itself has no server-side copy beyond the chosen storage. The storage provider’s retention policy therefore remains part of recovery.
Locking the vault removes the decrypted virtual view. Applications with an open file can delay a clean lock, and unsynchronized encrypted changes still depend on the cloud client finishing its upload. Cryptomator protects data before it enters that client; it does not monitor whether the provider completed synchronization.
