wslcontainers
Ask AI wslc 2.9.4.0

wslc --privileged, --cap-add, and FUSE mounts

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

Some workloads need Linux capabilities that normal containers do not get. The most common example is FUSE mounting — tools like CVMFS stream software into a container over a FUSE mount at /cvmfs. On Docker you would run with --privileged or --cap-add SYS_ADMIN --device /dev/fuse.

## What wslc 2.9.4.0 lacks | Flag / capability | Docker | wslc 2.9.4.0 | |---|---|---| | --privileged | ✅ | ❌ Rejected | | --cap-add SYS_ADMIN | ✅ | ❌ Rejected | | --cap-drop | ✅ | ❌ Rejected | | --device /dev/fuse | ✅ | ❌ Rejected | | --device /dev/kfd (AMD GPU) | ✅ | ❌ Rejected | | --gpus all | ✅ | ✅ Supported | Every one of the rejected flags fails with the same message: Argument name was not recognized for the current command: '--privileged'. ## The FUSE / CVMFS blocker The concrete scenario that exposes this (tracked in microsoft/WSL #41181): a container needs --privileged — or more granularly --cap-add SYS_ADMIN + --device /dev/fuse — to mount a CVMFS FUSE filesystem and stream neuroscience software modules at /cvmfs/example. Without capability injection or device access, wslc cannot run this workload. There is no workaround using current flags; mounting CVMFS on the host and sharing it is the only path, and it is fragile. ## Why the design is like this wslc's security posture (see the security guide) is: stronger isolation (per-session Hyper-V VM) but a deliberately narrow feature surface. No --privileged means a compromised container cannot easily escalate — but it also means legitimate privileged workloads have nowhere to go. This is a preview trade-off, not a bug. ## What to do if you need capabilities today 1. Run the privileged workload on Docker Desktop (or Docker Engine inside a WSL distro) and use wslc for everything else. The two coexist. 2. Restructure to avoid privileged access — e.g. mount the data on the host and share it over VirtioFS instead of FUSE-inside-container. 3. Watch the issue. microsoft/WSL #41181 is the tracker for --privileged / --cap-add / --device support. When it closes, this page changes. For the GPU-specific slice of the same gap (no --device breaking AMD ROCm), see the GPU troubleshooting page.

Related guides