Automating vault locking via Windows


My goal is to automagically lock the vaults when a user locks the Windows workstation. That way if the laptop is stolen, all vault data would be encrypted. My vaults reside on local drives C: and D:. Google drive sync is setup for the vault on C: drive. The D: drive is an SD card with a vault for backup in case the hard drive crashes.

I can delete the vault drives via command line using the ‘net use /delete’ command, but the Cryptomator interface does not get updated and still shows the vault being unlocked. As expected, the unencrypted vault drives no longer display on my PC. If I close Cryptomator via the tray icon and reopen it, then the vaults appear locked and require a password to unlock.

I also tried to kill the Cryptomator task via command line ‘tskill’, but upon restart the Cryptomator loses the setting for the static drive letter assignment, which would break future backup automation.

C:>net use
New connections will not be remembered.

Status Local Remote Network

         B:        \\cryptomator-vault@42427\5OKYU6AQSX5m\CryptoTest
                                            Web Client Network
         S:        \\cryptomator-vault@42427\hEXjhcr2Te7B\SD_Test
                                            Web Client Network

The command completed successfully.

C:>net use /delete b:
b: was deleted successfully.
C:>net use /delete s:
s: was deleted successfully.

C:>net use
New connections will not be remembered.
There are no entries in the list.

C:>fsutil fsinfo drives
Drives: C:\ D:\



  1. Does deleting the unencrypted vault drives via ‘net use’ actually lock the vaults? I want to make sure there is no way to get unencrypted data without requiring a password.

  2. Is there a cleaner way to automate vault locking? I am using the latest Cryptomator version 1.3.4 for Windows, but it does not yet have the option to autolock vault after predefined inactivity.

  3. I assume that if a PC is manually rebooted or via an uncontrolled event like a crash, the vaults would be locked securely upon boot up, correct?

Thanks in advance!

I guess you mean the WebDAV Drive. No disconnecting this drive does not lock the vault. Its a feature that you can connect/disconnect the WebDAV Drive via Cryptomator Interface. Open it, klick your vault and klick the drop down field (see screenshot). You can also use your own WebDAV Client, if you do not want to use the Windows System Client.

If you disconnect via net use, you can just connect it again via the cryptomator interface (without entering the password, as the vault is still open)

No, actually there’s no such function. A feature request is open.

The vault will be locked. Its locked as soon as the cryptomator process ends.

As @Michael already pointed out, there is no clean way yet.

If you want a 100% secure way to eliminate all cleartext artifacts and dont mind if a file inside the vault gets damaged by „force ejecting“ the drives, you can just kill the Cryptomator process. This will not harm the vault other than said interruption of write access to open files.

Thanks to all for helpful replies! I will look forward to the new auto-lock feature(s) and research into other suggested WebDAV client options.

Hi everyone! Just dropping by to +1 this feature request.

I’ve tried to script autolock myself on entering sleep mode via Windows Task Scheduler. Turns out when you ask cryptomator.exe to shutdown nicely with taskkill, it just hides its window and continues to run. Having a scriptable way to lock everything (apart from killing outright), would be already half a solution.

But I’m all for a proper timeout/inactivity thing. I need to protect files against a physical attack, like break-in, “hands off your computer”, pull all cords, carry away. Right-clicking a tray menu is way too slow for such an event.

Force the taskkill command with /F and it will also kill the background process and lock your vaults.

Yep, I know - that’s what I mean by “killing outright”.

This way the process is terminated, access to vaults is halted, but drives are not unmounted and remain stuck until a reboot (or maybe manual unmount).

This makes taskkill /F unusable for “normal” workflow, like closing the lid of a notebook.