Cryptomator on Windows: Accessing your vault with admin priviliges

Hey Community,

UPDATE: The most recent solution can be found in our docs: Volume Type — Cryptomator 1.7.0 documentation

when using WinFSP/FUSE or Dokany on Windows, you might have the following

The Problem: Processes (aka programs) do not have access to an unlocked vault, even when Cryptomator is started with admin privileges.

The Reason:
You mounted the vault to a drive letter. To make the virtual drive visible to all users (including elevated), you would need either admin privileges or specify a special flag.

The Solution:
Mount to a directory instead.

Hope it helps.

Remark: People complain that if they start Cryptomator with admin privileges they cannot access the unlocked vaults anymore. The reason of it is the same as above: They tried to access the vaults with their user account and not the one of the administrator.


Since I’m not familiar with how Windows handles user privileges in detail:

How big of a risk is it to remove the CURRENT_SESSION flag? Don’t have all programs I start or have running on Windows have the right to access my files anyway?

PS: I’m referring to a use case where I’m the only one with a user account on the machine.

1 Like

According to the Dokany documentation, the flag does the following:

Mount the drive on current session only

I guess its more a question of visibility rather than user priviliges.

No, not necessarily. Like in the Linux world you have different groups, each having their own access rights. Even if you are the only user on your machine, there exists several built-in accounts. Among those is for example the “Anonymous Logon” group, which by default has no rights. At system startup there may be processes started without your user id and thus may have different rights.

In general I would say the risk is low. If you have an account on a multi user system you should be aware of it but otherwise you can remove the option safely.

Thanks for clarifying!

I have just tried and without --options CURRENT_SESSION any users on the system has read/write access to the mounted vault

1 Like

I had the same issue with not seeing my mounted drive when starting Cryptomator as admin (SyncBack can’t see the Cryptomator drive) and removing --options CURRENT_SESSION solved it.

Before this topic was linked to me by @infeo, thus fixing my problem, I also realized something. The reason why people can’t access the unlocked vaults via normal means - Windows Explorer is that explorer.exe is not running as admin. That’s also the reason why some copy etc. operations in the system drive show a UAC prompt.

For anyone who doesn’t want to remove --options CURRENT_SESSION and wants to run Cryptomator as admin, a simple workaround is to access the vault by running a third party file explorer as admin. Another thing I was contemplating before applying this fix was to make a task using Task Scheduler, to run Cryptomator as admin on startup instead of using the built-in option. This might be a good solution for those who don’t want all users to access the unlocked vault, but also don’t want to manually start Cryptomator as admin every time.

I am new to using Cryptomator. I am using version 1.5.8 under Windows 10. I was trying to use Windows File History with my backup stored inside a Cryptomator vault, however, the drive list excludes the mounted vault. I wanted to try what was mentioned in this thread. Can someone tell me where to input --options CURRENT_SESSION ? I don’t see any place under preferences were I can insert this. Is there a file that must be edited?

  1. check that your cryptomator connector is set to dokany (cryptomator preferences)
  2. check that your vault for wich you want to change the session preferences is is closed
  3. Select your vault and click “Vault preferences”
  4. enter your parameter here:

Thank you - I didn’t realize that menu had disappeared after the vault had been unlocked. Unfortunately, removing the --options CURRENT_SESSION flag did not make the mounted Cryptomator vault drive show up in the Windows File History backup drive list. I have done this with Veracrypt before, and it would see the Veracrypt mounted drive, but I wanted to try Cryptomator with an eye toward syncing to cloud storage.

FYI: while moving back to my good, old Boxcryptor I have found that with current v1.5.11-190 the above trick isn’t working anymore

I concur - this bypass is broken in 1.5.11.

I also checked it, and yes, it does not work. For a workaround, see here:

confirmed :+1: :wink:

BTW: using the option “Personalized path” (translated from Italian since I cannot force English UI) the mounted folder is always available for everyone even using the default Mount options
Using build 1.5.12 (exe-2653.213)

the suggested solution works with dokany. but i’m using fuse/winfsp. what would be the equivalent option/setting for fuse?

…what a shame… :unamused:

Hi everyone,
I followed instruction reported at:

to configure into the register the parameter EnableLinkedConnections to make mapped volume available for both standard and admin user.

Unfortunately this parameter doesn’t seem to work anymore on the latest windows 10 builds. Do you know if there is chance to make it work or another way to achieve the goal ?

Thank You,


I updated and simplified the reason and solution. Should make things way easier. :slightly_smiling_face:

Hi, I have the same issue. While opening Cryptomator as admin did solve the problem I was having, I couldn’t access the unlocked vault anymore as stated in infeo’s post. So I followed the steps about ‘–options CURRENT_SESSION’ and when I switched from FUSE to dokany, I can’t unlock my vault anymore with error code TMN6:3HIN:SRPV. So I switched back to FUSE.

I’m not sure to understand how to fix my isssue. My user account is my administrator account. I only have one user on Windows.

“Solution: mount to a directory.”

Just want to make sure I understand this correctly because in my mind I already mounted to a directory. The problem would be if the Vault is mounted to say G:. But if you mount to G:/ABC, then it would be fine? Is that correct?

Basically yes. Of course, you need also permission to access all parents (in this case just G:\) of the mountpath with the accessing user.