Inside WSL, an SSH private key stored under /mnt/c/Users/... always reports mode 0777, `chmod 600` does not stick, and ssh refuses to use the key. Why does the permission change not persist, and how do you resolve it?

## What DrvFs is WSL mounts Windows volumes into the Linux namespace under `/mnt` using a filesystem called **DrvFs**. It is a bridge, not a Linux filesystem: it presents NTFS content through the Linux VFS interface. Bridges have to answer questions the underlying store cannot: a Linux `stat()` demands a `uid`, a `gid` and a mode, and NTFS has none of those — it has security descriptors with SIDs and ACLs, which are a richer but structurally different model. ## Why the mode reads 0777 By default DrvFs answers that question by **fabricating** the values rather than reading them from the volume. Every file is reported as owned by the WSL user, and the mode is derived from the mount options — `umask`, `fmask` (files) and `dmask` (directories) — not from the file's actual Windows ACL. With the permissive defaults, ordinary files come back as `0777`. The crucial consequence: there is nowhere to *write* a Linux mode. `chmod` on such a mount has no persistent effect — depending on version it either fails or appears to succeed and then reports the synthesized mode again on the next `stat`. Nothing is broken; the filesystem simply has no field to store the value in. The converse is just as important: tightening the file's real Windows ACL (with `icacls`, say) does not change what Linux sees, because DrvFs is not translating ACLs into mode bits in the first place. ## Why ssh cares OpenSSH refuses to use a private identity file that is accessible to group or other — its strict-modes check exists precisely to stop a key from being usable by everyone on a shared machine. It examines the file's permission bits, so a key reporting `0777` is rejected regardless of who runs `ssh`; running the command under `sudo` does not bypass the check. ## Fix 1: enable metadata on the mount DrvFs can store Linux metadata in **NTFS extended attributes**. Turn it on in `/etc/wsl.conf` inside the distribution: ```ini [automount] options = "metadata,umask=22,fmask=11" ``` Then shut the distribution down (`wsl --shutdown` from Windows) so the drives are remounted. After that, `chmod` and `chown` on `/mnt/c` persist, because the values are written into extended attributes on the file. Know the caveats before recommending it: - The metadata is meaningful only to WSL. Windows tools do not read or maintain it. - Files created by Windows applications carry no such attributes and fall back to the synthesized defaults. - Some Windows operations that rewrite a file (copy, save-as, sync clients) can drop the attributes, so the mode silently reverts. - It changes the meaning of permissions on a shared volume without changing the actual Windows access control — the file may be locked down in Linux's view while still readable by every Windows account. ## Fix 2: keep the file where real permissions exist The better answer for credentials and dotfiles is to stop straddling the boundary. Put the key in `~/.ssh` inside the Linux filesystem, which is a real ext4 filesystem under WSL2 with genuine inode ownership and mode bits, and `chmod 600` it there. It is faster too, and it avoids the whole class of "the mode reverted after Windows touched the file" incidents. Treat `/mnt/c` as the place for artifacts you hand to Windows, not the place your Linux tooling's state lives. If the same key genuinely must serve both Windows and Linux clients, keep the canonical copy on the Linux side and export a copy for the Windows tool, rather than sharing one file and fighting its metadata. ## Related boundary gotchas worth knowing - **Case sensitivity.** Linux directories are case-sensitive; NTFS directories are case-insensitive by default, so `Makefile` and `makefile` collide on `/mnt/c`. Windows can mark an individual directory case-sensitive with `fsutil.exe file setCaseSensitiveInfo <dir> enable`. - **Symlinks.** Creating Linux symlinks on a Windows drive is constrained by what NTFS and Windows privileges allow, which surprises build systems that expect free symlinking. - **Line endings.** Files edited by Windows tools arrive with CRLF, which breaks shell scripts executed from Linux with an obscure `bad interpreter` style error. ## What the interviewer is checking That you recognise a *model mismatch* rather than a bug: two access-control systems, one bridge, and a default that fabricates the missing fields. Bonus signal for knowing both fixes and for preferring the one that does not depend on fragile extended attributes.