[1.5.0 - 1.5.19] Empty Vault, but still allocates Space

Help Known Issues
1

This article applies to: Cryptomator Desktop Version 1.5.0 to 1.5.19

Error Description

After unlocking the vault, it appears empty. Also, your Cryptomator version is below 1.6.0.

Reason

Most probably this is due to either an incomplete sync or a file/folder conflict.

Each Cryptomator vault has a root folder as the entry point to the vault content from which you can reach all other content. To this root, like any other directory inside a vault, corresponds one encrypted directory.

If your sync client does not download this root directory or rename it due to a conflict, Cryptomator assumes that the vault was never opened before and recreates the missing directory. Therefore the vault seems empty, even thou it uses storage space.

Example

You have created a new vault myVault. Since Cryptomator 1.5.5, there is always an onboarding file placed inside new vaults called WELCOME.rtf. If you unlock your vault and mount it at the DriveLetter Z:\, you have the following two directory structures:

At the mount point the vault shows

MyVault (Z:\)
\---WELCOME.rtf

and at its storage location

.\myVault
|---IMPORTANT.rtf
|---masterkey.cryptomator
|---masterkey.cryptomator.6068F6C7.bkup
\---d
    \---7I
        \---CRG3VASBVR3MLFNH3ITUAWKD3P6JF2                  <-- root directory
            \---DZ7Qo0um08yn1TEJNZ4H143Tjuy8Sxi7IKDB.c9r    <-- encrypted WELCOME.rtf

Let’s say your sync client only partially synchronize your vault to a new pc and specifically forget to download the directory CRG3VASBVR3MLFNH3ITUAWKD3P6JF2. The vault is can be still openend with Cryptomator, because the masterkey is present and the d directory exists. But since the data root is missing, it thinks the vault wasn’t opened before and need to be initialized and therefore, creates it again(!). Already at this step, the vault will be shown empty when unlocked. Maybe after a while the sync client is able to download the old root, but detects a conflict and takes the newer version, leading to the following vault structure:

.\myVault
|---IMPORTANT.rtf
|---masterkey.cryptomator
|---masterkey.cryptomator.6068F6C7.bkup
\---d
    \---7I
        |---CRG3VASBVR3MLFNH3ITUAWKD3P6JF2_conflict         <---old root directory
        |   \---DZ7Qo0um08yn1TEJNZ4H143Tjuy8Sxi7IKDB.c9r    <-- encrypted WELCOME.rtf
        |
        \---CRG3VASBVR3MLFNH3ITUAWKD3P6JF2                  <---new, empty root directory

Remark

The above is an example with a new vault to help you understand the problem. Normally, a vault can have a lots of two character folders and each of them can have several subfolders. The root folder is also not necessarily the “first” listed.

Solution/Workaround

To check if this is the case, you need to find out which path in the vault storage location contains your vault root. On the computer, where the vault is not broken, unlock the vault and place a file inside it at the top directory. Your cloud provider should notify you that an (encrypted) file is uploaded. Its file path points to the vault root. On your other computer, where the vault is broken, check if this filepath is also present. (including the file!)

Once you have confirmed it, remove the newly created root directory (and backup its data) and either rename or redownload the original one.

3 Likes