Linux users are definitely familiar with chown and chmod console tools. These two apps are essential when it comes with permission and ownership management. Recently, Microsoft has made a number of improvements to these tools in their very own Linux subsystem bundled with Windows 10.
Advertisеment
You can now set the owner and group of files using chmod/chown and modify read/write/execute permissions in WSL. You can also create special files like fifos, unix sockets, and device files. It was a long awaited feature for many WSL users.
Another interesting change is new mounting options with DrvFs file system for projecting permissions onto files alongside providing new Linux metadata on files and folders.
There's one step you must take before you can enjoy these new features: You must unmount drvfs and remount it with the 'metadata' flag. To do this, enter the following commands at the Terminal:
sudo umount /mnt/c sudo mount -t drvfs C: /mnt/c -o metadata
You can verify that it mounted correctly by running "mount -l" to see something like this:
DrvFs is a filesystem plugin for WSL which adds support for interop between WSL and the Windows filesystem. DrvFs enables WSL to mount drives with supported file systems under /mnt, such as /mnt/c, /mnt/d, etc.
DrvFs adds a number of new mount options. They are as follows:
The new mount options include:
- uid: the user ID used for the owner of all files
- gid: the group ID used for the owner of all files
- umask: an octal mask of permissions to exclude for all files and directories.
- fmask: an octal mask of permissions to exclude for all regular files.
- dmask: an octal mask of permissions to exclude for all directories.
See the following example:
sudo mount -t drvfs C: /mnt/c -o metadata,uid=1000,gid=1000,umask=22,fmask=111
After executing the mount command, you will see your mount (in this case, C:) listed with all the parameters you passed in when querying for a list of mounted devices.
This change will allow mounting Windows folders and partitions under another user account in WSL rather the default one.
With this change, Linux permissions with be stored as an additional metadata for a file. This will allow storing both Linux and Windows permissions for a single file. Now you can change permissions in both WSL or Windows separately without breaking the environment. As you may remember, modifying Linux files from Windows could break WSL earlier.
Newly created files in WSL will be created with metadata by default and will respect the mount options you've set.
Important Caveats
There are a few things to make sure you're aware of when tinkering with the new metadata:
Editing a file using a Windows editor may remove the file's Linux metadata. In this case, the file will revert to its default permissions.
Removing all write bits on a file in WSL will make Windows mark the file as read-only.
If you have multiple WSL distros installed or multiple Windows users with WSL installed, they will all use the same metadata on the same files. The uid's of each WSL user account might differ. This something to consider when setting permissions.
For example, you can disable write permissions on a file in Windows and chmod the file to show write permissions are enabled in WSL. Or you can have read permissions enabled under Windows and remove read permissions in WSL. You can see this concept illustrated below.
Source: Microsoft.
Support us
Winaero greatly relies on your support. You can help the site keep bringing you interesting and useful content and software by using these options:
If you like this article, please share it using the buttons below. It won't take a lot from you, but it will help us grow. Thanks for your support!
Advertisеment
Does this require an Insider build? I tried to do this on a completeley updated WSL on Fall Creators Update (1709, 16299.192) , and I got the following:
$ uname -a
Linux lttganton 4.4.0-43-Microsoft #1-Microsoft Wed Dec 31 14:42:53 PST 2014 x86_64 x86_64 x86_64 GNU/Linux
$ sudo umount /mnt/d
$ sudo mount -t drvfs D: /mnt/d -o metadata
mount: wrong fs type, bad option, bad superblock on D:,
missing codepage or helper program, or other error
In some cases useful info is found in syslog – try
dmesg | tail or so.
I think this requires Windows 10 build 17063 and above.
Actually the 1803