WSL Automount and fstab Lifecycle: Make Mount Ownership Explicit

WSL exposes two mount mechanisms that are frequently collapsed into one: automatic mounting of Windows fixed drives and processing Linux /etc/fstab entries during distribution startup. In current Microsoft documentation, [automount] enabled controls whether fixed drives such as C: are automatically mounted with DrvFs; root changes their mount root; options adds DrvFs-specific options; and mountFsTab controls whether /etc/fstab is processed when WSL starts. The documented defaults enable both automatic Windows-drive mounts and fstab processing.

These settings are per distribution because /etc/wsl.conf belongs to a distro. They do not mean every filesystem is mounted by the same component or at the same stage. A reliable configuration names which mechanism owns each mount, keeps its options in the correct file, and verifies the resulting mount table after startup.

Separate the two policies

The [automount] section controls WSL’s behavior for Windows fixed drives. By default, a Windows C: volume appears at /mnt/c; changing root to /windir changes the expected path to /windir/c. enabled=false prevents automatic mounting, but Microsoft documents that the drive can still be mounted manually or through fstab. This is not a command to disable every Linux mount in the distribution.

mountFsTab=true means WSL processes /etc/fstab on distribution startup. The file is the Linux mount table used for other filesystems and mount definitions. It can include local Linux filesystems, bind mounts, or supported special filesystems. WSL documentation also mentions network filesystems as a use case, but this article focuses on local and volatile mounts so their failure and lifecycle can be tested independently of a network.

The configuration scopes are also different. /etc/wsl.conf is stored inside a specific distro, while %UserProfile%\.wslconfig configures global WSL 2 VM settings. A mount policy in one distribution does not automatically apply to another. Keep mount roots, directory creation, and fstab entries documented per distro.

Understand option scope and precedence

The options key under [automount] is for DrvFs-specific options and is applied to all automatically mounted Windows drives. Microsoft’s reference says that options normally parsed by the mount binary into flags are not supported through this automount option string. If a particular drive needs distinct options, use /etc/fstab and explicitly define each drive for which those flags are required. Do not assume a comma-separated automount string can express every Linux mount flag.

DrvFs options influence the Linux view of Windows files. Related settings such as metadata, uid/gid, masks, and case sensitivity have their own semantics and are documented separately. A global-looking option can affect all auto-mounted drives, so avoid adding it without checking the source documentation and testing a representative file. For mount options that belong only to a local Linux filesystem, place them in that filesystem’s fstab entry instead of the Windows-drive automount options.

If both automatic mounting and fstab entries target the same path, ownership becomes ambiguous and a duplicate mount can hide the original view. Pick one owner for each mountpoint. A clear policy might leave Windows drives to DrvFs automount and reserve fstab for a volatile tmpfs or a deliberately managed Linux filesystem.

Test fstab processing with a disposable local mount

In a noncritical distribution, create an empty mountpoint and add a small tmpfs entry to /etc/fstab:

set -eu
mountpoint=/mnt/wsl-volatile
sudo install -d -m 0755 "$mountpoint"
if findmnt --mountpoint "$mountpoint" >/dev/null; then
  printf '%s is already mounted; inspect it before continuing\n' "$mountpoint" >&2
  exit 1
fi
if [ -n "$(find "$mountpoint" ! -path "$mountpoint" -print -quit)" ]; then
  printf '%s is not empty; choose a disposable empty directory\n' "$mountpoint" >&2
  exit 1
fi
backup="$(sudo mktemp /etc/fstab.before-wsl-test.XXXXXX)"
sudo cp -a /etc/fstab "$backup"
printf '%s\n' 'tmpfs /mnt/wsl-volatile tmpfs rw,nosuid,nodev,size=64m,mode=1777 0 0' | sudo tee -a /etc/fstab
findmnt --verify --verbose

This uses a volatile in-memory filesystem with a small maximum size as a test. Data stored there does not provide durable persistence across shutdown. The guard refuses to cover an existing mount or hide files already in the directory; keep the test limited to disposable content and remove the fstab entry after validation. The backup path is printed by mktemp and can be used for recovery. findmnt --verify checks the fstab descriptions but does not prove WSL will process the file on the next start or that the mount succeeds in every environment.

Check the current runtime view and test the mount in a controlled way:

findmnt --mountpoint /mnt/wsl-volatile --output TARGET,SOURCE,FSTYPE,OPTIONS
df -hT /mnt/wsl-volatile
findmnt --mountpoint /mnt/c --output TARGET,SOURCE,FSTYPE,OPTIONS

If the mount is absent after a fresh start, inspect /etc/wsl.conf and confirm mountFsTab is not disabled. Stop and restart only the test distribution after saving work. WSL may continue running after a shell closes; use wsl.exe --terminate <Distro> from Windows to stop one distro or wsl.exe --shutdown to stop the shared WSL 2 VM. The latter affects every running distro.

Do not run a broad mount -a on a machine with unknown fstab entries as a casual validation step. It can attempt to mount every listed filesystem, including entries unrelated to the test. Read the file first and use a disposable distro or a targeted, understood command. If the test fails, restore the saved fstab carefully and re-check that the line was actually removed.

Startup, systemd, and failure ownership

WSL documentation specifies that fstab is processed on WSL start, but operators should not infer an undocumented ordering guarantee relative to every distribution service, systemd unit, or user session. If a service requires a mount, express and test the dependency through the distro’s supported init/service mechanism. Check whether systemd is enabled and what the relevant mount unit reports. A shell being available is not proof that every mount succeeded.

Mount failures can have different causes: an invalid source or target, missing mountpoint directory, unsupported filesystem type, option spelling, permissions, a busy device, or a dependency that is not ready. Capture the exact findmnt output, mount error, WSL version, distro release, fstab contents, and whether the failing path is DrvFs or a Linux filesystem. Do not respond to all failures by disabling automount; that may remove unrelated Windows drive access while leaving the original fstab issue untouched.

For reliability, avoid making an ordinary shell depend on a mount whose availability is not guaranteed. If a directory is expected to be empty when a mount is absent, consider the application behavior before using it as a fallback. A missing mount can cause writes to land in the underlying root filesystem directory and consume distro disk space. Use a readiness check that confirms the filesystem type and source, not merely that the path exists.

Windows-drive automount changes

When changing enabled, root, or options, review the active /etc/wsl.conf and preserve its other sections. Example:

[automount]
enabled=true
root=/mnt/
mountFsTab=true
options=metadata

This is illustrative, not a universal permissions recommendation. The metadata option changes how Linux permission metadata is represented for Windows files; use it only after reviewing Microsoft’s file-permissions documentation and testing existing data. If no custom option is required, omitting the line preserves the documented default behavior. Do not add a second [automount] header to a file that already has one.

If Windows drives must not appear automatically, use enabled=false and document which drives are intentionally mounted another way. Verify that scripts and editor settings do not hard-code /mnt/c if the mount root is changed. If scripts need to translate paths reliably, use wslpath instead of assuming a fixed drive root. Restart the distribution before testing the new mount layout.

Acceptance checks

Use a small matrix per distro: record wsl.exe --version, wsl.exe --list --verbose, the effective /etc/wsl.conf, /etc/fstab, and findmnt results. Test a cold distribution start and a warm invocation separately. Confirm that each expected mount has the correct source, type, target, and options. For Windows drives, test read/write behavior on a disposable file and confirm the path matches the configured root. For a local fstab mount, verify the expected filesystem type and source, then remove the test entry and ensure it disappears after restart.

A passing test does not mean every fstab entry is correct on every device. Test relevant WSL 1 and WSL 2 distributions separately because their filesystem and VM models differ. Repeat after changing WSL versions, distro init systems, volume letters, or mount options. Include a rollback procedure and protect useful data before changing mount ownership.

Operational ownership

Keep Windows fixed-drive mounts under the DrvFs automount policy unless a per-drive fstab definition is required. Use /etc/fstab for explicit Linux-side mounts and be clear about whether WSL, systemd, or an operator command is responsible for applying them. Validate at boot and at the point of use, not only by reading configuration. The important distinction is that enabled governs automatic Windows-drive presentation, whereas mountFsTab governs whether WSL processes Linux fstab entries at distribution startup.

Related:

Sources: