wslcontainers
Ask AI wslc 2.9.4.0

wslc volumes: bind mounts, named volumes and VirtioFS

Updated 2026-07-27 · 6 min read · wslc public preview

wslc volumes use the same -v / --volume / --mount flags as Docker. Host paths are shared over VirtioFS.

Bind mounts

# mount a Windows directory
wslc run -v C:/projects/myapp:/app -w /app node:22-alpine npm test

# mount with read-only flag
wslc run -v C:/config:/etc/app:ro myapp
Windows path rules
Use forward slashes: C:/work:/app.
Backslashes are rejected.
Relative paths are not accepted.

Named volumes

wslc volume create pgdata
wslc run -v pgdata:/var/lib/postgresql/data -e POSTGRES_PASSWORD=secret postgres:16-alpine
wslc volume ls
wslc volume rm pgdata

Permission notes

Files shared over VirtioFS appear with Linux-style ownership inside the container. If a container writes files to a bind-mounted Windows directory, they appear owned by the container's user from the Linux side. Use -u to run as a specific UID for consistent ownership.

Performance

VirtioFS throughput is substantially better than the 9p filesystem used in WSL 2. For database storage, named volumes are recommended because they avoid the VirtioFS overhead entirely — the volume lives in the utility VM's native filesystem.

What is missing

  • tmpfs — no equivalent in wslc 2.9.4.0.
  • NFS / CIFS volumes — no volume driver plugins.
  • Volume backup/restore — use wslc run with a bind mount to tar the volume contents.

Backup, restore and file copy

wslc 2.9.4.0 ships three commands that make volume and filesystem portability straightforward (all verified against the real CLI):

  • Copy fileswslc container cp CONTAINER:PATH .\local copies between a running container and the host, like docker cp. The reverse (.\local CONTAINER:PATH) copies in.
  • Snapshot a filesystemwslc export CONTAINER_ID -o backup.tar writes the container's filesystem as a tar archive.
  • Restore as an imagewslc import backup.tar myimage:latest turns that tarball back into a runnable image.

A pragmatic backup loop for a database volume is therefore: start the container, wslc export the filesystem to a tarball, and move the tarball to object storage. Because the volume lives inside the utility VM, exporting the container filesystem captures everything a bind-mounted backup from the Windows side would miss.

Related guides