My PC's OS is Windows 10, where I am hosting a Cryptomator volume on E: . I want to run bash commands on the contents of that mounted volume, thus, I am trying to access its contents with WSL.

It seems like this can't be achieved directly: I am trying to open the container on Windows and to mount the volume directly on WSL, which fails, as it seems to only work with Docany, currently not supported by the latest version of Cryptomator.

I am thus trying to use the Cryptomator CLI (https://github.com/cryptomator/cli) directly on WSL, where I aim to open the container directly. Unfortunately, when trying to mount the volume, I get:

  Password:  /sbin/mount.davfs: loading kernel module fuse
  modprobe: FATAL: Module fuse not found in directory /lib/modules/4.4.0-19041-Microsoft
  /sbin/mount.davfs: loading kernel module fuse failed  
  /sbin/mount.davfs: waiting for /dev/fuse to be created

fuse is supposed to be compiled into WSL 2 ("modprobe fuse" on WSL?), however, even though I execute the mknod command, I keep getting the same error.

EDIT: Updating WSL to the latest version on PowerShell solved the above issue: wsl --set-version Ubuntu-20.04 2.

Now, on the directory where I have stored cryptomator-cli-0.5.1.jar, I run the java command (obfuscating the password here for obvious reasons):

java -jar cryptomator-cli-0.5.1.jar --bind --port 8080 --vault firstVault=/mnt/e/myFolder/ --password firstVault='[###]'

I get the following output:

14:54:23.878 [main] INFO  o.c.frontend.webdav.WebDavServer - Binding server socket to
14:54:23.940 [main] INFO  o.e.jetty.server.AbstractConnector - Started ServerConnector@6a472554{HTTP/1.1, (http/1.1)}{}
14:54:23.950 [main] INFO  org.eclipse.jetty.server.Server - jetty-10.0.6; built: 2021-06-29T15:28:56.259Z; git: 37e7731b4b142a882d73974ff3bec78d621bd674; jvm 17.0.2+8-Ubuntu-120.04
14:54:24.091 [main] INFO  o.e.j.server.handler.ContextHandler - Started o.e.j.s.ServletContextHandler@3d0f8e03{/,null,AVAILABLE}
14:54:24.111 [main] INFO  org.eclipse.jetty.server.Server - Started Server@5a955565{STARTING}[10.0.6,sto=0] @1212ms
14:54:24.112 [main] INFO  o.c.frontend.webdav.WebDavServer - WebDavServer started.
14:54:24.112 [main] INFO  org.cryptomator.cli.frontend.WebDav - WebDAV server started:
14:54:24.144 [main] INFO  org.cryptomator.cli.CryptomatorCli - Unlocking vault "firstVault" located at /mnt/e/myFolder
14:54:24.145 [main] INFO  o.c.c.p.PasswordFromPropertyStrategy - Vault 'firstVault' password from property.
14:54:25.709 [main] INFO  o.e.j.s.s.DefaultSessionIdManager - Session workerName=node0
14:54:25.731 [main] INFO  o.a.j.w.server.AbstractWebdavServlet - authenticate-header = Basic realm="Jackrabbit Webdav Server"
14:54:25.733 [main] INFO  o.a.j.w.server.AbstractWebdavServlet - csrf-protection = null
14:54:25.733 [main] INFO  o.a.j.w.server.AbstractWebdavServlet - createAbsoluteURI = true
14:54:25.734 [main] INFO  o.e.j.server.handler.ContextHandler - Started o.e.j.s.ServletContextHandler@f478a81{/firstVault,null,AVAILABLE}
14:54:25.738 [main] INFO  o.c.f.w.s.WebDavServletController - WebDavServlet started: /firstVault
14:54:25.739 [main] INFO  org.cryptomator.cli.CryptomatorCli - Press Ctrl+C to terminate.

Back in Windows, I open Google Chrome and try to access, however, I get ERR_CONNECTION_REFUSED.

Is there something missing in order to access the Cryptomator volume with WSL?

  • 1
    That 4.4 kernel is very far out of date (the current Microsoft kernel is 5.10); I don't know when FUSE came into it, but possibly within that period, so I would update it. I don't know whether you can mount -t drvfs E: with a Cryptomator volume there either, but I would have thought so until now. Apr 9, 2022 at 0:19
  • @MichaelHomer this solved that issue, and now I am able to mount the drive, however, I am still unable to access it via localhost (see my updated question above).
    – jlnkls
    Apr 9, 2022 at 13:06

1 Answer 1


Is there any way to access the Cryptomator volume with WSL?

Probably -- I can't say for sure, but I do know that you won't be able to do it as you are currently configured. The kernel you are using shows that you are actually in WSL1, not WSL2 as you think.

  • WSL1 "pseudo-kernels" end in -Microsoft
  • WSL2 kernels end in -microsoft-standard-WSL2

It's not uncommon to think you are running WSL2 when you aren't. It could be:

  • Your computer doesn't support WSL2, so only WSL1 was installed to begin with (unlikely)
  • You originally installed WSL before WSL2 came out, then upgraded to WSL2, but didn't upgrade the distribution.
  • Your default version is set to WSL1, so the distribution was installed in that mode.
  • Or perhaps something went wrong on the WSL2 installation.

So let's check each of these:

Default version
wsl --status # Available on recent Windows/WSL releases

Does the status show the default version is 2? If so, good. If not, start by setting the default:

wsl --set-default-version 2
wsl --status

If you see a message like:

Please enable the Virtual Machine Platform Windows feature and ensure virtualization is enabled in the BIOS.
For information please visit https://aka.ms/wsl2-install

Then follow those instructions.

Otherwise, if wsl --status returns without error, proceed ...

Check the current distribution
wsl -l -v

Look at the list of distributions. Yours is almost certainly showing 1.

Convert distribution

You'll probably want a backup of your distribution before running the conversion. Exit WSL, then, from PowerShell:

$imagePath = "$env:USERPROFILE\WSL\images" # Edit if you want a different location
$distroName = "Ubuntu" # Edit with your distribution name, if different

wsl --terminate $distroName

mkdir $imagePath
wsl --export $distroName $imagePath\$distroname-backup.tar

Assuming the above ran successfully, complete the conversion with:

wsl --set-version $distroName 2
  • All my distros were already version 2 and the default one was also 2, however, the default distro was not the Ubuntu 20.04 one, but a docker distro I am using for other purposes. I have now set the Ubuntu 20.04 distro as the default one. Still, this doesn't solve the above problem: I am unable to access the vault via http://localhost:8080/firstVault/.
    – jlnkls
    Apr 9, 2022 at 14:10
  • @jlnkls Right - As said, I'm just not sure if you can; just that there was definitely a problem there. I'm still surprised that you are seeing a WSL1 kernel in a Docker distro that is reporting WSL2 in wsl -l -v, though. Something seems funky there, but probably no need to worry about it now that you've updated to the right distro. Apr 9, 2022 at 18:44

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .