chmod does not change WSL permissions? Check metadata and storage

You run chmod in WSL, but the file permissions do not change as expected. Even within the same Linux terminal, a file stored in the Linux filesystem and one opened through a Windows drive such as /mnt/c can follow different permission rules.

Checking the storage location and mount options first, then trying a small file you created yourself, gives you a better starting point than repeating chmod. The examples below use a WSL 2 Linux terminal with GNU coreutils df, stat, mktemp, and chmod, plus util-linux findmnt.

Identify where the file is stored

In your Linux terminal, move to the directory containing the file you are investigating. Display the current location and its filesystem.

pwd
df -T .

A directory in the Linux filesystem commonly shows ext4. A Windows drive path is another useful clue when working with Windows files. The filesystem Type can also appear as 9p for Windows drives in WSL 2, so inspect the mount information as well rather than relying on the type name alone.

You do not need to move an existing project as the first response to a permission problem. If you want to preserve your environment before changing settings or moving files, see backing up WSL and restoring a separate copy.

Check metadata on the Windows drive mount

findmnt -T . -o FSTYPE,OPTIONS

This command displays the filesystem and mount options for the current directory. Windows drive entries may include aname=drvfs and a Windows-side path. Whether metadata is enabled affects how Linux permissions are represented.

Microsoft describes two ways WSL obtains permissions for Windows files: deriving Linux-style bits from the Windows user’s access, or reading metadata attached by WSL. Metadata is not enabled by default. When used, it can store Linux ownership and mode information in NTFS extended attributes.

Consequently, chmod 600 on a Windows file without metadata need not produce the same displayed mode as it does on a regular Linux file. Treat a successful command exit, the displayed mode, and the access you actually need as separate observations.

Compare the change using a new test file

Run this example in a writable working directory. It creates a uniquely named temporary directory at the current location and changes only the new sample.txt inside it. To compare Linux storage with a Windows drive, run the same block separately in each location.

test_dir=$(mktemp -d ./wsl-permission-demo.XXXXXX) &&
printf 'permission demo\n' > "$test_dir/sample.txt" &&
stat -c '%a %n' "$test_dir/sample.txt" &&
chmod 600 "$test_dir/sample.txt" &&
stat -c '%a %n' "$test_dir/sample.txt"

Compare the first and last stat output lines. %a shows permission bits in octal and %n shows the filename. Mode 600 grants the owner read and write permissions, with no permissions for the group or others. The && chain stops the later operations if an earlier step, such as creating the temporary directory, fails.

For example, a mode that remains 777 without metadata does not by itself establish that the chmod syntax was wrong. Conversely, a displayed mode of 600 does not mean Windows applications now follow identical access rules. If you receive Permission denied, the location, ownership, and operations permitted by Windows provide useful next checks.

When finished, use the test_dir value in the same terminal to identify the temporary directory, then remove only the sample.txt and directory you created. Keep private keys and other important files out of this test.

Choose the next step for the storage location

If a tool relies on Linux permissions, consider whether its files can be kept in Linux storage. When the files need to stay on a Windows drive, review the existing metadata and mask options together with Windows permissions. Applying chmod 777 or sudo to every problem can move you further away from the restrictions you intended.

DrvFs automatic mount options can be configured in the distribution’s /etc/wsl.conf, under [automount]. Preserve the existing settings and compare the relevant options with Microsoft’s guidance, including their scope and the effect of restarting the distribution. Metadata and chmod cannot grant access that Windows permissions do not allow.

Private keys have their own storage and access requirements. Reading a general file’s mode and choosing a safe place for authentication material are related decisions, but a mode display alone does not settle both.

References

• Microsoft Learn: WSL file permissions
• Microsoft Learn: WSL configuration
• util-linux manual: findmnt
• GNU coreutils manual: stat
• GNU coreutils manual: mktemp