Autostart working but mounting of drives fails (without an error message)

Hi,

I use Cryptomator 1.5.6 (Dokany) on Windows 10, Version 1909.
“Unlock vault when starting computer” is enabled.

Cryptomator starts automatically but fails to mount the drives at least every second time.
There is no error message.
I get the windows saying “Unlocked XYZ successfully! Your fault is now accessible”.
When I click reveal vault, I get an error message in Windows Explorer.

Manually locking and unlocking the vault helps every time. I can access my data without any problems after manually locking/unlocking the vault.

This is what the end of the log files looks like after mounting the drives failed:

	CreateDisposition -- OPEN_EXISTING
	createOptions -- EnumIntegerSet(elements=[])
	accessMasks -- EnumIntegerSet(elements=[])
	fileAccessMasks -- EnumIntegerSet(elements=[])
	fileAttributes -- EnumIntegerSet(elements=[]).
09:20:32.716 [Thread-858887] TRACE o.c.frontend.dokany.ReadWriteAdapter - (190576) cleanup() is called for /Dokumente/desktop.ini.
09:20:32.716 [Thread-858889] TRACE o.c.frontend.dokany.ReadWriteAdapter - (190575) cleanup() is called for /Dokumente/desktop.ini.
09:20:32.717 [Thread-858888] TRACE o.c.frontend.dokany.ReadWriteAdapter - Try to open / as Directory.
09:20:32.719 [Thread-858888] TRACE o.c.frontend.dokany.ReadWriteAdapter - (190578) / opened successful with handle 190578.
09:20:32.790 [Thread-858890] TRACE o.c.frontend.dokany.ReadWriteAdapter - (190576) closeFile() is called for /Dokumente/desktop.ini.
09:20:32.792 [Thread-858891] TRACE o.c.frontend.dokany.ReadWriteAdapter - (190575) closeFile() is called for /Dokumente/desktop.ini.
09:20:32.862 [Thread-858892] TRACE o.c.frontend.dokany.ReadWriteAdapter - (190578) getFileInformation() is called for /.
09:20:32.863 [Thread-858892] TRACE o.c.frontend.dokany.ReadWriteAdapter - (190578) Filesize of / is 4096.
09:20:32.863 [Thread-858892] TRACE o.c.frontend.dokany.ReadWriteAdapter - (190578) File Information successful read from /.
09:20:32.865 [Thread-858893] TRACE o.c.frontend.dokany.ReadWriteAdapter - (190578) cleanup() is called for /.
09:20:32.939 [Thread-858894] TRACE o.c.frontend.dokany.ReadWriteAdapter - (190578) closeFile() is called for /.
09:20:33.966 [Thread-515] INFO  com.dokany.java.DokanyDriver - Unmount and shutdown: M:\
09:20:34.068 [Thread-9] INFO  com.dokany.java.DokanyDriver - Unmount and shutdown: E:\
09:20:34.071 [Thread-13] INFO  com.dokany.java.DokanyDriver - Unmount and shutdown: M:\
09:20:34.073 [Thread-506] INFO  com.dokany.java.DokanyDriver - Unmount and shutdown: E:\
09:20:34.095 [App Background Thread 003] TRACE o.c.frontend.dokany.ReadWriteAdapter - unmounted() is called.
09:20:34.193 [ShutdownTasks] DEBUG org.cryptomator.common.ShutdownHook - Running graceful shutdown tasks...
09:20:34.196 [App Background Thread 006] TRACE o.c.frontend.dokany.ReadWriteAdapter - unmounted() is called.
09:20:34.211 [ShutdownTasks] DEBUG o.cryptomator.frontend.dokany.Mount - Unmounting drive E:\: ...
09:20:34.211 [ShutdownTasks] INFO  com.dokany.java.DokanyDriver - Unmount and shutdown: E:\
09:20:35.250 [ShutdownTasks] DEBUG o.cryptomator.frontend.dokany.Mount - Unmounted drive E:\: successfully.
09:20:35.263 [ShutdownTasks] DEBUG o.cryptomator.frontend.dokany.Mount - Unmounting drive M:\: ...
09:20:35.264 [ShutdownTasks] INFO  com.dokany.java.DokanyDriver - Unmount and shutdown: M:\
09:20:35.264 [ShutdownTasks] DEBUG o.cryptomator.frontend.dokany.Mount - Unmounted drive M:\: successfully.

I appreciate your help. Thanks!

According to the log file, your vault opened without a problem.

Do you have admin rights on the computer where the error occurs? If yes, can you please test the following:

  1. Start your Computer with the setting, that your vaults are unlocked at startup.
  2. Check if they are inaccessible
  3. If so, open an elevated terminal, (aka one with admin rights) and try to navigate to the vault

For example, if your vault is mounted at E:\, you just need to enter E: to change the current terminal directory to the vault location.

Yes, I have admin rights.

As I said, the problem occurs very often, but not every time.

  1. Done

  2. In Windows File Explorer, both drives are inaccessible.

  3. I am not exactly sure what you want me to do here. I have opened the Windows Command Prompt both without and with admin rights. In both cases, the system wasn’t able to find the drive.

Edit: As I said, if I manuall lock and unlock the vault again, the drives are mounted without any problems every time. The problem only occurs on auto-start.

It looks like other people are reporting the same or a very similar issue:
[Vault unlocks and assigns drive letter, but later the drive cannot be opened]

Yes, I have this problem, too. But I have it if I unlock the vault manually, as well, not just when the vault is unlocked automatically.

For me, the failure seems to occur if the vault is unlocked in the first few minutes after the system is booted. Doesn’t matter how it is unlocked. Once it fails, I can successfully unlock it manually if enough time has elapsed (say 3-5 minutes).

I hope the dev team is able to reproduce this and provide a fixed version. The only workaround for me is to manually unlock the vault later, but it is a nuisance to have to remember to do that.

Perfect description.
Sometimes - when I don’t interact with the computer for minutes while the system is booting - the vaults will get automatically unlocked. But not every time. I suppose another process may interference with the process in some way?

Windows 10, running Cryptomator 1.58 exe 174 (new release)

I can’t say if this behavior is new with this version.

I have a Cryptomator volume which is unlocked automatically when my system starts. This has been working flawlessly for months.

Suddenly, it seems the mount fails at startup. Cryptomator says the vault is unlocked, but there is no drive mapping. Reveal drives fails, as does any other access to drive (D:, my mount point).

Event logs show a dokany mount followed shortly after by an unmount. Cryptomator logs seem to indicate a mount timeout. See logs at bottom of this post.

If I lock/unlock the vault manually after this failure, the vault is successfully unlocked and mounted to drive (D:) is once again mounted and is accessible. As far as I know the mount failure only happens during system restart.

Perhaps the dokany mount is just taking a bit too long? If so is there a way to increase the timeout? Any other suggestions?

Thanks.

Logs

15:23:42.512 [main] INFO  org.cryptomator.launcher.Cryptomator - Starting Cryptomator 1.5.8 on Windows 10 10.0 (amd64)
15:23:54.087 [JavaFX Application Thread] INFO  o.c.ui.launcher.FxApplicationStarter - JavaFX Runtime started.
15:23:54.120 [JavaFX Application Thread] INFO  org.cryptomator.jni.FunctionsLoader - loaded WinFunctions.dll
15:23:55.768 [App Background Thread 003] INFO  com.dokany.java.DokanyDriver - Dokany version: 140
15:23:55.768 [App Background Thread 003] INFO  com.dokany.java.DokanyDriver - Dokany driver version: 400
15:24:03.780 [App Background Thread 003] WARN  o.c.frontend.dokany.MountFactory - Mounting timed out.
15:24:03.781 [App Background Thread 003] INFO  o.c.ui.unlock.UnlockWorkflow - Unlock of 'Cryptomator' succeeded.
15:25:34.926 [JavaFX Application Thread] WARN  o.c.keychain.KeychainManager - LOAD
15:25:36.810 [App Background Thread 006] INFO  com.dokany.java.DokanyDriver - Unmount and shutdown: D:\
15:25:38.440 [JavaFX Application Thread] INFO  o.cryptomator.ui.fxapp.UpdateChecker - Current version: 1.5.8, lastest version: 1.5.8
15:25:41.811 [App Background Thread 006] WARN  o.cryptomator.frontend.dokany.Mount - Dokany driver will be canceled now...
15:25:41.811 [App Background Thread 006] WARN  o.cryptomator.frontend.dokany.Mount - Dokany driver for drive D:\: canceled.
15:25:41.814 [JavaFX Application Thread] INFO  o.cryptomator.ui.common.VaultService - Locked Cryptomator
15:25:44.585 [App Scheduled Executor 01] INFO  o.c.common.settings.SettingsProvider - Settings saved to C:\Users\LARRY\AppData\Roaming\Cryptomator\settings.json
15:25:46.415 [App Scheduled Executor 02] INFO  o.c.common.settings.SettingsProvider - Settings saved to C:\Users\LARRY\AppData\Roaming\Cryptomator\settings.json
15:26:12.366 [App Background Thread 006] INFO  com.dokany.java.DokanyDriver - Dokany version: 140
15:26:12.366 [App Background Thread 006] INFO  com.dokany.java.DokanyDriver - Dokany driver version: 400
15:26:20.368 [App Background Thread 006] WARN  o.c.frontend.dokany.MountFactory - Mounting timed out.
15:26:20.368 [App Background Thread 006] INFO  o.c.ui.unlock.UnlockWorkflow - Unlock of 'Cryptomator' succeeded.
15:26:22.621 [App Background Thread 006] INFO  com.dokany.java.DokanyDriver - Unmount and shutdown: D:\
15:27:00.062 [JavaFX Application Thread] INFO  o.cryptomator.ui.quit.QuitController - Locked 
15:27:00.081 [main] INFO  org.cryptomator.launcher.Cryptomator - UI shut down
15:27:00.089 [Thread-174] INFO  com.dokany.java.DokanyDriver - Unmount and shutdown: D:\
15:27:00.090 [Thread-8] INFO  com.dokany.java.DokanyDriver - Unmount and shutdown: D:\

Some additional notes. The mount timeout seems to be the cause of the problems. This seems to be happening if Cryptomator is unlocked when the system is very busy (for example during startup or within the first minute or two after restart).

The “Mounting timed out” message seems to be occurring about 8 seconds after the unlock attempt. Changing the dokan --timeout setting to 60 seconds has no effect (if I am doing it correctly); the timeout still occurs after 8 seconds.

Happy to do any special testing needed.

Seems several others are experiencing a similar issue:

Vault unlocks and assigns drive letter, but later the drive cannot be opened

Autostart working but mounting of drives fails (without an error message)

I’d guess it’s actually the same problem. For me this only started happening recently, but I’ve tried back-level releases back to 1.5.0 and they all are now exhibiting the same behavior. I did not change the dokany version when I tried those other versions, though.

Did you try the workaround that is described? Does it work for you too?

Thanks for responding.

Not sure what workaround you mean. I cannot use WebDav because it doesn’t support some file access methods I need (RealtimeSync does not work because it cannot monitor the directory for changes).

What does work for me is to not unlock at system start, but rather wait 3-5 mins and then manually unlock. None of the other things I have tried have worked (reinstalling CM, re-creating the vault, going to old release of CM (>= 1.5.0)

Here is a debug log showing the failure. You will see the mount timeout at 10:24:09.214. Later, when I try to access the file system, it fails. The log entry shows mounted() / unmounted() when that happens (last two entries in the log).

If I wait a few minutes and then lock/unlock the vault, everything is OK.

The most dangerous behavior is that there is a short period of time after the reported timeout that the volume is actually mounted. It dismounts after a minute or so. Presumably if file activity starts during the period when it is mounted some filesystem corruption might occur when the dismount happens.

10:23:48.767 [main] INFO  org.cryptomator.launcher.Cryptomator - Starting Cryptomator 1.5.8 on Windows 10 10.0 (amd64)
10:23:48.779 [main] DEBUG org.cryptomator.logging.DebugMode - Debug mode enabled
10:23:48.780 [main] DEBUG org.cryptomator.launcher.IpcFactory - [Client] Reading IPC port from C:\Users\LARRY\AppData\Roaming\Cryptomator\ipcPort.bin
10:23:48.781 [main] DEBUG org.cryptomator.launcher.IpcFactory - [Client] Connecting to port 49850...
10:23:52.093 [main] DEBUG org.cryptomator.launcher.IpcFactory - [Client] Failed to connect.
10:23:52.145 [main] DEBUG org.cryptomator.launcher.IpcFactory - [Server] Wrote IPC port 49818 to C:\Users\LARRY\AppData\Roaming\Cryptomator\ipcPort.bin
10:23:52.147 [main] DEBUG o.c.launcher.IpcProtocolImpl - Received launch args: 
10:23:52.148 [main] DEBUG org.cryptomator.launcher.Cryptomator - Did not find running application instance. Launching GUI...
10:23:57.630 [main] DEBUG o.c.ui.traymenu.TrayIconController - initialized tray icon
10:23:57.637 [main] DEBUG o.cryptomator.ui.launcher.UiLauncher - Hiding application...
10:23:57.644 [main] DEBUG org.cryptomator.common.CommonsModule - Starting App Background Thread 001
10:23:57.648 [main] DEBUG org.cryptomator.common.CommonsModule - Starting App Background Thread 002
10:23:57.650 [App Background Thread 001] DEBUG o.c.ui.launcher.FxApplicationStarter - Starting JavaFX runtime...
10:23:59.493 [JavaFX Application Thread] INFO  o.c.ui.launcher.FxApplicationStarter - JavaFX Runtime started.
10:23:59.554 [JavaFX Application Thread] INFO  org.cryptomator.jni.FunctionsLoader - loaded WinFunctions.dll
10:23:59.877 [JavaFX Application Thread] TRACE o.cryptomator.ui.fxapp.FxApplication - FxApplication.start()
10:24:00.260 [JavaFX Application Thread] DEBUG o.c.k.WindowsProtectedKeychainAccess - Attempting to load keychain from C:\Users\LARRY\AppData\Roaming\Cryptomator\keychain.json
10:24:00.279 [JavaFX Application Thread] DEBUG org.cryptomator.common.CommonsModule - Starting App Background Thread 003
10:24:00.279 [JavaFX Application Thread] DEBUG o.cryptomator.ui.fxapp.FxApplication - Showing UnlockWindow for Cryptomator
10:24:00.299 [JavaFX Application Thread] DEBUG o.c.common.vaults.VaultStats - stop recording stats
10:24:00.301 [JavaFX Application Thread] DEBUG o.c.ui.launcher.AppLifecycleListener - Allow quitting without prompt: false
10:24:00.326 [App Background Thread 003] DEBUG o.cryptomator.cryptofs.ReadonlyFlag - Vault opened for read and write.
10:24:01.207 [App Background Thread 003] INFO  com.dokany.java.DokanyDriver - Dokany version: 140
10:24:01.208 [App Background Thread 003] INFO  com.dokany.java.DokanyDriver - Dokany driver version: 400
10:24:01.208 [App Background Thread 003] DEBUG o.c.frontend.dokany.MountFactory - Mounting on D:\: ...
10:24:01.210 [App Background Thread 003] DEBUG org.cryptomator.common.CommonsModule - Starting App Background Thread 004
10:24:04.212 [App Background Thread 003] TRACE o.cryptomator.frontend.dokany.Mount - Mounting still in progress.
10:24:09.214 [App Background Thread 003] WARN  o.c.frontend.dokany.MountFactory - Mounting timed out.
10:24:09.215 [App Background Thread 003] INFO  o.c.ui.unlock.UnlockWorkflow - Unlock of 'Cryptomator' succeeded.
10:24:09.221 [JavaFX Application Thread] DEBUG o.c.common.vaults.VaultStats - start recording stats
10:24:09.223 [JavaFX Application Thread] DEBUG org.cryptomator.common.CommonsModule - Starting App Background Thread 005
10:24:10.223 [JavaFX Application Thread] DEBUG org.cryptomator.common.CommonsModule - Starting App Background Thread 006
10:26:37.054 [App Background Thread 004] TRACE o.c.frontend.dokany.ReadWriteAdapter - mounted() is called.
10:26:37.054 [App Background Thread 004] TRACE o.c.frontend.dokany.ReadWriteAdapter - unmounted() is called.


I meant using dokany with a custom mount point.

Yes, custom mountpoint on empty directory works fine. Reluctantly I have moved to that approach until the drive mount processing is fixed.

This new method has some shortcomings. For example, Adobe reader cannot open PDFs in that file system (Access Denied). Don’t know why but I will check it out.

Anyway, drive letter mounts are much preferred, at least by me.

EDIT: The Adobe reader issue is known issue with Adobe (not CM specifically) see https://github.com/cryptomator/cryptomator/issues/909

Hello, everyone,

i use Cryptomator 1.5.5 under Windows 10. Cryptomator starts automatically on system startup and should unlock my safe in the dropbox automatically (Dokany 1.3.1.1000 / don´t want to use WebDAV). This sometimes works, but very often it does not.

Would it be possible to realize an optional delayed unlocking of the safe? I think crypotmator has a problem to unlock a dropbox safe if the dropbox is not synchronized yet.

I had this problem too. (Win 7 with magenta-Cloud.)
I start now Cryptomator with 30 sec.
Works fin.

We found the reason for issue: It is a problem (deadlock) in Dokany itself.

For more information and updates, check

As a short update, the first hunch is most probably not the problem, but the direct unmount is still created by Dokany. One reason can be the usage of AV software. To gather evidence, is anyone experiencing this issue
using a Kaspersky Security product?

For workarounds, to access the files again, see this comment.

Dokany released a new version today: https://github.com/dokan-dev/dokany/releases/tag/v1.4.1.1000, which includes fixes for the issues mentioned in the linked bug ticket. Since we still cannot reproduce this issue, we need people testing and reporting back.

In order to use th new lib, the one shipped with Cryptomatr (C:\Program Files\Cryptomator\dokan1.dll) must be renamed to a different name (e.g. foo.dll)

1 Like
  • Dokany v1.4.1.1000 (manually updated)
  • Windows 10 Professional, Version 20H2
  • Windows Defender, no Kaspersky or other third-party security product
    -> issue persists