Vault Local Custom Location Catastrophic Failure

Could you please explain why I get consistent catastrophic failures every time I attempt to open a vault in a custom location? This has been happening for years and I’m very tired of trying to figure out a workaround every time it happens. Today I discovered, merely by accident, that if I designate all of my vaults as default vaults then they will open without issue. I do not understand the mindset of why Cryptomator is designed to operate this way. What is so special about a default vault? My vaults are not default vaults. They are just random vaults in different locations on my phone. I should be able to select a vault anywhere on my phone and just open it the same way as on my PC. Could you please why these extreme complications are designed into the functionality of Cryptomator?

1 Like

With this error description I am not in a position to tell you what is going wrong but maybe if you describe exactly what kind of errors occur, how they show up and what you have to do to make them happen. Providing a log file could also help: How do I enable debug mode on Android?

The “Default storage” vs “Custom locations” is a different implementation of accessing files in the local storage of the phone. “Default storage” uses the API and the “Default storage” the Storage Access Framework. The Storage Access Framework does support accessing files on external devices such as SD cards while does not allow this.
The reason why we have the version is because of legacy reasons, Storage Access Framework is only available since Android version 5.0 and our min supported version currently is Android 4.3.

I am currently trying to open vaults on a Samsung Galaxy Note 9/Android 10 in the internal memory. When I point cryptomator to the vault, select the masterkey, the window opens indicating that the vault is selected but there is no vault name in the window, and if I try to select it to input my password I get a catatonic type failure that says cryptomator failed to open the vault. I had this same problem on my Galaxy Note 4, and I have had to develop a workaround every time it happens. This is the first time I ever tried identifying the vaults as default vaults which actually worked. In the past I always created new vaults on my phone then copied all my files into the new vaults then everything would work fine from that point on. I don’t understand why I cannot just point cryptomator to a vault/master key and just open my vault similar to Windows 10. This has actually been happening for years on 2 different phones.
The Storage Access Framework does not seem to have ever worked properly on either of my Note 4 or Note 9 phones as far as opening vaults in internal memory. I’m curious if it actually opens vaults in internal memory on any phone. Maybe you should change the nomenclature to Internal Memory and External Memory instead of Default and Local, and it might eliminate the confusion/complications.
Thanks for Cryptomator and your awesome support by the way!

If the vault name is empty the problem is, that the masterkey file is in the root of the internal storage and not in the folder with the name of the vault. The Android app doesn’t handle this case well. A workaround would be to move the d folder, the masterkey files and optionally the m folder in a new created folder. After that unlocking the vault should work as expected.

What exactly does not worked properly? Do you see any kind of error message while unlocking a vault? It should definitely work with vaults in internal storage. We tried to describe in our documentation what is possible with each implementation:

Because Android changed the way permissions handled while accessing files, sooner or later the Storage Access Framework version will be the only one left.

1 Like

My bad. I never realized the Storage Access Framework worked like this. Your solution solved the problem. I will make a note to myself to hopefully avoid any future issues. As always, thank you for your outstanding assistance!

1 Like

To document this in a proper way we just created an issue on the Github repo: