What I did was an assumption and failed miserably as you will see what I did to have this issue.
First, all files were encrypted and a vault was made. No issues.
All copies were then sent to online storage. Now, I only sent data directory while keeping the rest locally.
Since now I have two copies, one with and another without encryption. Decided to delete the encrypted files by accessing the vault using desktop app.
Next to check my theory, I downloaded back the data files from online storage and placed it under the encrypted vault along with precise names of each folder and paths.
Unfortunately, this reverse method of decryption using app failed.
So in summery:
Files Encrypted - Stored Online - Files Deleted Locally
Restored Online Files - Can’t Access Content
Does that mean that there is no way of going back once the files are deleted from vault even when these files can be imported back from online storage?
Currently, I have to keep two copies of same files. And I did above to save space as I had already backed up data directory to the cloud.
I also have no clue as to how to use Santizer but would be willing to if that could help.
No. There’s clearly something going wrong in your process. Can you please confirm that there was no sync after you deleted you local vault?.
If you have a complete vault online, you can just download all the vault files (including the vault root where the masterkey file is located). Then you can ad that downloaded vault to your local cryptomator app and decrpyt it with you password.
If you want to check weather you online vault is ok, you can access it directly via cyberduck.
Sync could not be the cause these are browser only uploads. My question is does deleting files somehow also make any change to meta folder too and can this affect the decrypting of files? My data folder was backed up online but rest of the files were kept locally.
What do you mean by that? Do you refer with “data folder” to the d directory inside a Vault? The internal structure of a vault (hence all files/directories inside your vault storage location) is not meant to be split up/partially backed up.
Yes, the folder “d” was backed up online and the rest were kept untouched locally. Only moved data to cloud and than restored back to test.
The backup of data folder was done over browser manually. Nothing was split or damaged as rest of the folders along with masterkey were kept on local drive.
So only deleted data folder. Then imported back online. Now, it shows empty even when the downloaded structure is same as it was created.
Okay, since this is clear now, i need to state the obvoius question: Why would you do that? There is absolutley no reason to do such a thing.
Apart from that, it should work as long as you masterkey file and other files in the m directory are untouched. Does your log contain any ERROR or WARN messages?
I can imagine that during up- or download the data might be slighty altered and therefore you get unauthenticated ciphertext warnings.
Log:
14:27:52.177 [main] INFO org.cryptomator.launcher.Cryptomator - Starting Cryptomator 1.4.15 on Windows 10 10.0 (amd64)
14:27:52.583 [main] INFO o.c.launcher.IpcProtocolImpl - Received launch args:
14:27:52.873 [JavaFX Application Thread] INFO org.cryptomator.launcher.Cryptomator - JavaFX application started.
14:27:52.999 [JavaFX Application Thread] INFO org.cryptomator.jni.JniModule - loaded WinFunctions.dll
14:27:53.040 [JavaFX Application Thread] INFO o.c.ui.controllers.MainController - Unable to setPreferencesHandler, probably not supported on this OS.
14:27:55.299 [JavaFX Application Thread] INFO o.c.k.WindowsProtectedKeychainAccess - Unable to load existing keychain file, creating new keychain.
14:28:03.092 [Background Thread 2] INFO com.dokany.java.DokanyDriver - Dokany version: 130
14:28:03.092 [Background Thread 2] INFO com.dokany.java.DokanyDriver - Dokany driver version: 400
I had to delete the data folder because of space limitation. So I deleted the data folder. Kept the rest. Also have the original data obviously.
Something new:
App repopulates folder structure even the its data is deleted. Somehow the app “remembers” the folders names. But this didn’t happen to this case. This happened when I once again tested with a new file right now. And now if I move the file back to this automatically populated folders, then surprisingly I get the data back!
Since I am testing here, I deleted entire folder “d” and note that I earlier didn’t deleted this folder but only the content of it. This created another issue. Now the app asks to generate a new password. So I once again made this folder. And now asked for the regular password to access the vault.
If you want to free up space, simply move the whole vault directory to some external storage space rather than ripping it apart.
But that aside, you can simply put it back together and unlock it. If it doesn’t work, it isn’t the original structure.
Well if the app notices that your storage location is not containing vault data (because it got deleted in this case), it assumes you want to initialize a vault here. If you now proceed (no matter if using the same password as before or a different one), it will generate a new key which can not be used to access your old data.
Already on external drive but this is a huge data so have to make some space.
How come the app recreates entire folder tree only sometimes after deletion of data inside of it? Where does folder names info get stored? As in one case no folders were repopulated by the app but another it did.
Short answer: Cryptomator doesn’t “store” folder names. During directory creation a unique directory id is generated. The only exception is the root directory, which is always the same for a given key.
Do I need to restore all folders to back so the app can recognize data or is there an option to restore few as needed? In my case, I had only got about 10 percent of folders back from online. Does that mean I have to download all the folders back to access few data?
So this is what happened:
Cryptomator surprisingly restored only one single folder structure out of countless many. And this one single folder is the key to decrypt the data folders I had downloaded back.
So now the question is how come a single folder was recreated in a way that app failed to decrypt data for other folders? How come a single folder dominated the rest?
Some more info: This particular folder only contained files in KBs. Note that only referring to folder “d” here.
Please share some light.
Steps taken to get data back:
Deleted entire data drive “d” after making an online backup.
Was unable to get data back even with right files and folders.
Noticed that app would only recreate a single folder back in “d” folder. That prompted below steps.
App recreated only folder back once I mounted the vault.
This folder was empty.
Restored back its content along with folder tree manually.
Folder now has original structure back with files having few KBs.
Locked the vault.
Next, I put back the other folders with tree and data.
Unlocked the vault and got the data back!
Your description does not make it clear for me what happend. Let’s start at the beginning and unravel the problem from there.
Basic Info
First of all, I would like to have some information about your setup:
What system do you use?
What is your cloud provider?
What is your Cryptomator version?
What vault provider do you use to access the vault? (WebDAV/FUSE/Dokany)
What happend
Now lets state the sequence of actions:
You created locally a vault.
You uploaded the complete vault to an online storage. -> Automatically with some sync software or manually?
You deleted on your local hard drive the d directory of the vault storage location. -> did you tried to open this vault in the mean time?
Then you downloaded the online stored d directory again and copied it into the root of your vault.
You unlocked the vault, but when you wanted to browse its content, no cleartext files were shown inside the vault (e.g. at the access point of your vault).
From here things get a little hazy for me, so maybe you can help out.
You use the term “app”. Do you still refer to the desktop application?
Then you say, that "app recreate only a single folder in d". What do you mean with that? I thought that no files inside the unlocked vault were shown. Or did the “app” something with the d directory of your vault?
Afterwards, you say that you “restored the content along with folder trees manually”. Does this mean you copied unencrypted data from outside into the access location of your unlocked vault?
In the next sentence you write about that the “folder” has its original structure. Which folder? Inside your vault (at its access location) or do you mean a folder at the storage location?
System: Windows 10 Enterprise 1903 64-bit Cloud: OneDrive for Business Version: 1.4.15 Type: Dokany
Note: I am transferring only encrypted folders and files to restore data by putting them under “d” folder.
Vault made locally.
Transferred only “d” folder to cloud. Rest are local.
Deleted “d” folder. Vault was not re-opened meanwhile.
Downloaded “d” folder back.
Vault unlocked. Empty vault. Won’t detect restored content.
(But the encrypted “d” drive now has this one folder recreated but it is empty.)
Steps Taken:
Desktop App
I put back the encrypted content of above single folder (KBs. sized files.) back from downloaded data. Then put back remaining data. Vault now showed all data.
Note that the vault only was able to detect/read/decrypt my data when I had put back all the files of this folder.
Had I only put pack selected data back, minus this folder, vault shows an empty drive.
This particular and only folder was auto-generated upon unlocking the vault. So I placed its content back (KBs files.). Now I placed back the remaining folders with data. Vault now detected everything.
Note that this folder was auto-generated but it is not new. It was also there before in the original structure. When the vault was opened, it only recreated this folder in “d” drive, but without any sub-folders or content.
So I want to know what’s going on with this auto-generated folder mechanism? Only after putting back its content, I was able to get data read again.
is the encrypted initial root directory of your vault (the strings may differ). It is always created if Cryptomator does not detect any data in your d directory.
What I gather from your descriptions are, that you tried to partially restore your vault in the wrong way (e.g. adding the files/folders at the wrong point). For more info about the architecture/directory structure, have a look at our docs.