Version 1.4.13: drive not connected

After a new windows start, the drive associated with the decrypted files is “not connected”. I have to manually disconnect and reconnect the vault. After this, everything works fine. What can I do to fix the problem and regain the previously comfortable situation when the startup worked automatically?

Like this?

(Source: Issue #951 on GitHub)

Maybe this is a new bug introduced in Dokany 1.3.1000…

No–in windows explorer, everything looks alright, but when I click on any file or folder, the following message pops up:

Does this change if you switch to Cryptomator 1.4.11?

I assume from the picture you are using Dokany as the unlocked vault provider. Did you recently updated Dokany?

And is your vault located on a network drive?

Up to version 1.4.13, it worked fine; do you suggest, I should step back to version 1.4.11 for a test?
I never updated Dokany on my own. If it has been updated recently, then only bundled with a cryptomator update, not separately.
Yes, my vault resides on a WD MyCloud in my LAN.

The problem with Dokany is, that it can not be updated automatically. You have to remove it, restart and install the new version. This isn’t ideal and we’re in contact with the Dokany developers to improve the situation.


Is this an old version that I should update? If yes, which version should I use and where download from?

1.2.0.1000 is fairly up-to-date. Not sure if 1.3.0.1000 fixes your issue. @infeo What do you think?

The official Dokany download site is here (you want to choose DokanSetup_redist.exe).

Or you can re-run the Cryptomator installer, which has 1.3.0.1000 bundled.

I suggest to update since there are some downward incompabilites of Dokany 1.3.1000 and we use on our side already this version of the dll-library. But I can’t say if this will fix the specific issue.

I deinstalled Dokany 1.2, then re-run the Cryptomator 1.4.13 installation exe, but Dokany was not simultaneously re-installed. So, I downloaded DokanSetup_redist.exe (Version 1.3, as suggested) and everything workes fine after a Windows reboot.
Thank you all for your speedy help! :grinning:

1 Like

Unfortunately, the problem is not yet solved. After a windows restart:
CryptomatorProblem2
The folder “AsthPriv” lost connection and was renamed “Lokaler Datenträger” (local media).
After disconnecting and reconnecting the vault, everything is back to normal - any ideas?

I reinstalled version 1.4.12 - that one works for me!

We just released 1.4.15, where we removed the access via an UNC path. Can you try this version?

If not, can you send me a log file when you unlock and try to access a file? Upload the log file with Firefox Send and shoot me a PM with the link.

Unfortunately, I need a network drive and UNC to access my NAS. What makes you assume a version without this would solve the problem I reported? (Version 1.4.12 works fine, version 1.4.13 doesn’t–what has been changed?)

Let me rephrase it: In 1.4.13 you had additional access to the unlocked vault over a UNC path. This UNC path was removed due to some problems, see #943 and #951. You can still access your NAS and the locked vault since they are provided over the built-in windows library. (in contrast to the unlocked vault, which is provided by Dokany)

I can confirm that version 1.4.15 works properly–thx!

Sorry–version 1.4.15 does not work reliably (same problem as with 1.4.13)! I reinstall version 1.4.12 which worked fine.

I set cryptomator to "automatically connect on startup (experimental - still!?). I have the impression that my NAS takes too long to wake up. Therefore, cryptomator can’t connect properly.
How can I be sure my NAS is up and running, before cryptomator tries to automatically connect?

That can’t be solved with Cryptomator.

That said, feel free to open a feature request for a delayed auto unlock. Maybe there are other users who would benefit from this feature.

Thanks for the suggestion. I tried out the following startup batch:
ping -n 10
start /D “C:\Program Files\Cryptomator” /MIN Cryptomator.exe
pause
exit
The connection is successful but deteriorates within minutes: First, Windows Explorer depicts the network drive with its proper name, then, the name changes to “drive Z:” without any accessible files. I think I will step back to a previous version…