Panic - Vault empty

Help Desktop App
1

Hi

I tried to unzip a large archive (~500MB) in my vault. During the decompression I got an access error (insufficient rights). Tried to lock/unlock the vault and now it is empty! No error no nothing. Any suggestions? Reboot didn’t help. Disk space is not an issue since I have 30GB free space.

Same in German:
Ich hab versucht ein großes Zip Archiv (~500MB) in meinem Vault zu entpacken. Während des dekompremierens bekam ich die Meldung “Unzureichende Zugriffsrechte”. Habe daraufhin versucht den Vault zu schließen und neu zu öffnen, jetzt ist er komplett leer. Kein Fehler, einfach nur nichts. Jemand ne Idee? Neustart hat nichts gebracht. Festplatte ist nicht das Problem, darauf sind noch 30GB frei.

System:
MacOS Big Sur (11.1), 32GB Ram
Cryptomator 1.5.11

Logfile:
12:14:50.456 [App Background Thread 006] INFO o.c.ui.unlock.UnlockWorkflow - Unlock of ‘Workspaces’ succeeded.

2

What “volume type” are you using for the “virtual drive”? You can check that out in the Cryptomator settings. WebDAV or FUSE?

3

Tried both, they were always “empty”.

4
  • Where is your vault located (cloud storage)?
  • Are you sure that you just locked and unlocked the vault? Nothing happened in-between?
  • If you open the masterkey backup files with a text editor, are there multiple masterkey files with the same version?
  • Does your vault resemble anything like the vault structure? Mainly, that there is a folder d with 2-char folders and inside them 30-char folders?
5

Its on a self hosted Nextcloud (synced dir, not webdav), but at the time of the incident the synchronisation was paused since 2 hours ago. So no interference from Nextcloud.

When I got the message “Invalid access” I waited for the zip archive to extract. So I’m quite sure nothing happened in between.

Jan 22 11:54 masterkey.cryptomator.36D80944.bkup contains only one key.
(Checked the other for fun, also only one key)

The file structure does match the file structure described in the link.

6

Regarding my third question: Cryptomator always creates a backup of the masterkey file after a successful unlock. There were rare cases about “empty” vaults if the masterkey file didn’t match the encrypted vault contents. It happened because somehow the masterkey file was replaced with a different/unrelated one.

That’s why my idea was to check the version number inside of each backup file and if there were multiple ones with version: 7. If that’s the case, you could rename and try the different masterkey file(s). But be aware not to just use one with version: 6 or lower because once you’ve done a vault upgrade, the upgraded vault contents are incompatible with lower versions.

And I assume that you’ve already checked if the size of the vault is somewhat reasonable and there should still be some data?

You could enable debug mode, unlock your vault, and check if there any suspicious messages that might hint at the unexpected behavior.

7

The keys are idential to the versions from this morning (where everything was still working).
The encrypted vault size is ~30 GB which is the expected size.

Debug unlock log:

16:54:51.202 [JavaFX Application Thread] DEBUG o.cryptomator.ui.fxapp.FxApplication - Showing UnlockWindow for Workspaces
16:54:51.202 [JavaFX Application Thread] DEBUG o.c.common.vaults.VaultStats - stop recording stats
16:54:51.202 [JavaFX Application Thread] DEBUG o.c.ui.launcher.AppLifecycleListener - Allow quitting without prompt: false
16:54:51.204 [App Background Thread 006] DEBUG o.cryptomator.cryptofs.ReadonlyFlag - Vault opened for read and write.
16:54:51.424 [App Background Thread 006] DEBUG o.c.c.common.MasterkeyBackupHelper - Verified backup file: /SOURCE/Workspaces/masterkey.cryptomator.36D80944.bkup
16:54:51.425 [App Background Thread 006] DEBUG o.c.c.m.CustomMountPointChooser - Successfully checked custom mount point: /DESTINATION/Workspace-Crypted
16:54:51.461 [Thread-64] TRACE o.c.frontend.fuse.ReadOnlyAdapter - statfs / (73566056448 / 499963174912)
16:54:51.461 [Thread-63] TRACE o.c.frontend.fuse.ReadOnlyAdapter - statfs / (73566056448 / 499963174912)
16:54:51.462 [Thread-66] TRACE o.c.frontend.fuse.ReadOnlyAdapter - statfs / (73566056448 / 499963174912)
16:54:51.462 [Thread-65] TRACE o.c.frontend.fuse.ReadOnlyAdapter - statfs / (73566056448 / 499963174912)
16:54:51.462 [Thread-67] TRACE o.c.frontend.fuse.ReadOnlyAdapter - statfs / (73566056448 / 499963174912)
16:54:51.463 [Thread-68] TRACE o.c.frontend.fuse.ReadOnlyAdapter - statfs / (73566056448 / 499963174912)
16:54:51.464 [Thread-69] TRACE o.c.frontend.fuse.locks.LockManager - Creating ReadWriteLock for []
16:54:51.464 [Thread-69] TRACE o.c.f.fuse.locks.PathRLockImpl - Acquired read path lock for '[]'
16:54:51.464 [Thread-69] TRACE o.c.frontend.fuse.locks.LockManager - Creating ReadWriteLock for []
16:54:51.464 [Thread-69] TRACE o.c.f.fuse.locks.DataRLockImpl - Acquired read data lock for '[]'
16:54:51.465 [Thread-69] TRACE o.c.frontend.fuse.ReadOnlyAdapter - getattr / (lastModifiedTime: 2021-01-22T10:45:20.672891506Z, lastAccessTime: 2021-01-22T10:45:20.783760688Z, creationTime: 2020-11-14T16:26:47Z, isRegularFile: false, isDirectory: true, isSymbolicLink: false, isOther: false, size: 1280, fileKey: (dev=1000004,ino=53446771))
16:54:51.465 [Thread-69] TRACE o.c.f.fuse.locks.DataRLockImpl - Released read data lock for '[]'
16:54:51.465 [Thread-69] TRACE o.c.f.fuse.locks.PathRLockImpl - Released read path lock for '[]'
16:54:51.465 [Thread-70] TRACE o.c.frontend.fuse.ReadOnlyAdapter - statfs / (73566056448 / 499963174912)
16:54:51.465 [Thread-71] TRACE o.c.frontend.fuse.ReadOnlyAdapter - statfs / (73566056448 / 499963174912)
16:54:51.465 [Thread-72] TRACE o.c.frontend.fuse.ReadOnlyAdapter - statfs / (73566056448 / 499963174912)
16:54:51.465 [Thread-73] TRACE o.c.frontend.fuse.ReadOnlyAdapter - statfs / (73566056448 / 499963174912)
16:54:51.465 [Thread-74] TRACE o.c.frontend.fuse.ReadOnlyAdapter - statfs / (73566056448 / 499963174912)
16:54:51.468 [Thread-78] TRACE o.c.frontend.fuse.ReadOnlyAdapter - statfs / (73566056448 / 499963174912)
16:54:51.468 [Thread-76] TRACE o.c.frontend.fuse.ReadOnlyAdapter - statfs / (73566056448 / 499963174912)
16:54:51.468 [Thread-81] TRACE o.c.frontend.fuse.ReadOnlyAdapter - statfs / (73566056448 / 499963174912)
16:54:51.468 [Thread-82] TRACE o.c.frontend.fuse.ReadOnlyAdapter - statfs / (73566056448 / 499963174912)
16:54:51.468 [Thread-87] TRACE o.c.frontend.fuse.ReadOnlyAdapter - statfs / (73566056448 / 499963174912)
16:54:51.468 [Thread-85] TRACE o.c.frontend.fuse.ReadOnlyAdapter - statfs / (73566056448 / 499963174912)
16:54:51.468 [Thread-79] TRACE o.c.frontend.fuse.ReadOnlyAdapter - statfs / (73566056448 / 499963174912)
16:54:51.468 [Thread-86] TRACE o.c.frontend.fuse.ReadOnlyAdapter - statfs / (73566056448 / 499963174912)
16:54:51.468 [Thread-83] TRACE o.c.frontend.fuse.ReadOnlyAdapter - statfs / (73566056448 / 499963174912)
16:54:51.468 [Thread-88] TRACE o.c.frontend.fuse.ReadOnlyAdapter - statfs / (73566056448 / 499963174912)
16:54:51.468 [Thread-75] TRACE o.c.frontend.fuse.ReadOnlyAdapter - statfs / (73566056448 / 499963174912)
16:54:51.468 [Thread-77] TRACE o.c.frontend.fuse.ReadOnlyAdapter - statfs / (73566056448 / 499963174912)
16:54:51.468 [Thread-84] TRACE o.c.frontend.fuse.ReadOnlyAdapter - statfs / (73566056448 / 499963174912)
16:54:51.469 [Thread-89] TRACE o.c.frontend.fuse.ReadOnlyAdapter - statfs / (73566056448 / 499963174912)
16:54:51.468 [Thread-80] TRACE o.c.frontend.fuse.ReadOnlyAdapter - statfs / (73566056448 / 499963174912)
16:54:51.469 [Thread-90] TRACE o.c.frontend.fuse.ReadOnlyAdapter - statfs / (73566056448 / 499963174912)
16:54:51.469 [Thread-91] TRACE o.c.frontend.fuse.ReadOnlyAdapter - statfs / (73566056448 / 499963174912)
16:54:51.470 [Thread-92] TRACE o.c.frontend.fuse.ReadOnlyAdapter - statfs / (73566056448 / 499963174912)
16:54:51.470 [Thread-93] TRACE o.c.frontend.fuse.ReadOnlyAdapter - statfs / (73566056448 / 499963174912)
16:54:51.471 [Thread-94] TRACE o.c.frontend.fuse.ReadOnlyAdapter - statfs / (73566056448 / 499963174912)
16:54:51.471 [Thread-95] TRACE o.c.frontend.fuse.ReadOnlyAdapter - statfs / (73566056448 / 499963174912)
16:54:51.471 [Thread-96] TRACE o.c.frontend.fuse.ReadOnlyAdapter - statfs / (73566056448 / 499963174912)
16:54:51.471 [Thread-97] TRACE o.c.frontend.fuse.ReadOnlyAdapter - statfs / (73566056448 / 499963174912)
16:54:51.472 [Thread-98] TRACE o.c.frontend.fuse.ReadOnlyAdapter - statfs / (73566056448 / 499963174912)
16:54:53.434 [App Background Thread 006] INFO  o.c.ui.unlock.UnlockWorkflow - Unlock of 'Workspaces' succeeded.
16:54:53.446 [JavaFX Application Thread] DEBUG o.c.common.vaults.VaultStats - start recording stats
16:55:03.742 [Thread-99] TRACE o.c.frontend.fuse.locks.LockManager - Deleting ReadWriteLock for []
16:55:03.742 [Thread-99] TRACE o.c.frontend.fuse.locks.LockManager - Creating ReadWriteLock for []
16:55:03.742 [Thread-99] TRACE o.c.f.fuse.locks.PathRLockImpl - Acquired read path lock for '[]'
16:55:03.743 [Thread-99] TRACE o.c.frontend.fuse.locks.LockManager - Deleting ReadWriteLock for []
16:55:03.743 [Thread-99] TRACE o.c.frontend.fuse.locks.LockManager - Creating ReadWriteLock for []
16:55:03.743 [Thread-99] TRACE o.c.f.fuse.locks.DataRLockImpl - Acquired read data lock for '[]'
16:55:03.743 [Thread-99] TRACE o.c.frontend.fuse.ReadOnlyAdapter - getattr / (lastModifiedTime: 2021-01-22T10:45:20.672891506Z, lastAccessTime: 2021-01-22T10:45:20.783760688Z, creationTime: 2020-11-14T16:26:47Z, isRegularFile: false, isDirectory: true, isSymbolicLink: false, isOther: false, size: 1280, fileKey: (dev=1000004,ino=53446771))
16:55:03.743 [Thread-99] TRACE o.c.f.fuse.locks.DataRLockImpl - Released read data lock for '[]'
16:55:03.743 [Thread-99] TRACE o.c.f.fuse.locks.PathRLockImpl - Released read path lock for '[]'

On opening the mountpoint of the vault with finder I get the nice message:
“The folder XXX cant be opened because you dont have permission to see its contents”

8

Have you tried changing the custom mount point? Maybe something is indeed wrong with the permissions? Or maybe use the “default”/automatically-chosen mount point?

9

Just checked the permissions and there where something I did not expect. The decrypted vault was missing the execute flag, which prevented the use of the folder as well a folder. After chmod +x on the folder and I could access it again.