wslc volumes: bind mounts, named volumes and VirtioFS
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 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 files —
wslc container cp CONTAINER:PATH .\localcopies between a running container and the host, likedocker cp. The reverse (.\local CONTAINER:PATH) copies in. - Snapshot a filesystem —
wslc export CONTAINER_ID -o backup.tarwrites the container's filesystem as a tar archive. - Restore as an image —
wslc import backup.tar myimage:latestturns 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.