Fix Windows Subsystem for Linux (WSL) File Permissions
Windows 10 is my daily driver at home so I need a way to use some Linux command-line utilities (e.g. git) without having to boot-up a virtual machine. I used Cygwin in the past but I really like the familiarity of the Ubuntu toolchain. Fortunately Microsoft introduced Windows Subsystem for Linux (WSL) a while ago so I can now have my cake and eat it too.
I have not done a ton of research but it appears that the emulated Linux filesystem is sandboxed and is stored on actual disk in some place that is not human friendly. The good news is that WSL can “mount” Windows drives under
/mnt, the bad news is that it does an awful job of emulating anything near good Linux file permissions. What this means in practice is that every file has permissions 0777 which causes me issues because git will preserve the execute bit on tracked files.
The fix has two pieces: fixing how WSL mounts Windows drives and then fixing the permissions for newly created files.
Fixing WSL Mount Permissions
The short version is to add this section to your WSL instance’s
/etc/wsl.conf (the file probably does not exist, just create it):
[automount] enabled = true options = "metadata,umask=22,fmask=11"
What it Does
You can read the “official” Microsoft documentation on their Dev Blog but here is my explanation line-by-line:
automountsection changes the settings for drives that are automounted under
enabledkey is probably unnecessary but it explicitly turns on automounting (default is
optionskey is a bit more interesting:
metadataturns on a mostly parallel of file permission metadata that allows WSL file permissions changes to be persisted. It partially affects the underlying Windows permissions; for more details see the Dev Blog link above.
umaskvalue masks out (i.e. unsets) the group and others write bit for both files and directories
fmaskvalue masks out the group and others execute bit for just files
Files should now show up with a comfortable permission setting of 0644 and directories with 0755 if they’re mounted under
Fixing Bad Default Permissions
This is kind of separate from the mounting problem but newly created files and directories in the “real” Linux directory structure also get a bad set of default permissions: 0666 for files and 0777 for directories. This is controlled by the
umask value which defaults to 0000 in WSL. There is a decently long bug report about this issue but the fix is easy enough. Add to your
# Note: Bash on Windows does not currently apply umask properly. if [[ "$(umask)" = "0000" ]]; then umask 0022 fi
Similar to the
umask setting that we used in our
/etc/wsl.conf the value of 0022 masks out the group and others write bit for both files and directories.