Chmod/Chown WSL Improvements


We've added new file system features to WSL in Insider Build 17063. 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. We're introducing new mounting options with DrvFs 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: 

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 the output below:

What is DrvFs?

DrvFs is a filesystem plugin to WSL that was designed to support 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. 

You can learn more about DrvFs and the WSL filesystem in a previous blog post from June 2016, WSL File System Support, which covers the Linux filesystem as it pertains to WSL and compares it to the Windows filesystem. 

Let's take a look at the two new features in detail. And remember, some of the functionality discussed below already exists on the Linux filesystem side—bringing this over to the Windows side is what's new. 

Support for Additional Metadata

Linux permissions are added as additional metadata to the file. This means a file can have Linux and Windows read/write/execute permission bits.

How did permissions work in the past?

Prior to Build 17063, all files/folders list "root" as the owner and belonged to the group "root". The permission bits on each file/folder was derived from Windows permissions--no write bit checked for Windows meant no write bit set in WSL.

Additionally, attempting to chmod or chown on a file/folder resulted in a no-op (they wouldn't do anything!)

How do permissions work now?

For files that don't have metadata, we apply the same approach as what is described in pre-17063 builds. But now, chmod/chown can assign metadata to the file or folder. Newly created files in WSL will be created with metadata by default and will respect the mount options you've set (discussed later) or the permissions you pass when executing a mkdir/open.

Once the file or folder has metadata, Windows and Linux permissions will not remain in lock-step with each other.

Important Caveats

There are a few things to make sure you're aware of when tinkering with the new metadata:

  1. 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
  2. Removing all write bits on a file in WSL will make Windows mark the file as read-only.
  3. 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.

In the example below, I remove a file's write permissions in WSL which disables the ability to write changes to the file from WSL. But I can still open the file and write changes from Windows because I have the write permission set in Windows.

Inversely, if I have a file in WSL which states its Linux permissions allows writing--but I've disabled write permissions in Windows--I still won't be able to perform actions. Windows permissions for a file or folder will trump the permissions set under WSL. You can see this concept illustrated below.

Special Files

You can create special files like fifos, unix sockets, and device files.

Mount Options

We've added new mount options to DrvFs to control permissions for files without metadata. You can combine with the metadata option to specify default permissions for files without metadata. 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.

A sample command using the mount options could look like this: 

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. 

If you're unfamiliar with octal masks, consult the man pages for chmod to learn more (in the WSL console, enter "man chmod"). 

Mount Options Example

In my WSL instance, I have created a group called "metadatagroup" and a user named "msbob". They have gid and uid values equal to 1001. I also have a file and folder without metadata in WSL. If I mount DrvFs with this command:

sudo mount -t drvfs C: /mnt/c -o metadata,uid=1001,gid=1001,umask=22,fmask=111

Take a peek at the permissions on the file and directory that did not previously have metadata. It was appropriately assigned msbob and metadatagroup for the owner and group bits, as expected.

Additionally, because we passed in umask=22 and fmask=111, our files and directories have had their read/write/execute permissions update accordingly. The umask used in this example will disable execution rights for files by default, which allows you to be more explicit in setting execution permissions on a file-by-file basis.

By default, WSL will set the uid and gid to the default user with drives that are auto-mounted during instance start. If you mount manually, you will have to set these explicitly (the default user that gets created when WSL is first installed has a uid=1000 and gid=1000).

What do you think about the latest changes to DrvFs? Drop us a comment below or tweet at us! 

Cheers,

Craig Wilhite (@CraigWilhite)

 

Comments (13)

  1. Damien Solodow says:

    Since the C: drvfs mount isn’t in /etc/fstab, is there a way to make the ‘-o metadata’ persist across instance starts aside from a umount/mount in rc.local?

    1. Yes, we’re working on another blog post to highlight how to set some WSL configs which will be read upon startup each time. It’ll address your question, stay tuned.

  2. john says:

    how about fixing the problem with unix and windows not allowing certain characters in their file names .. Makes alot of things impossible when you try to use these mnt drives ..

  3. John Doe says:

    I cannot create unix sockets on drvfs with metadata.

    1. What the blog post says is that you can create “special files” (including unix socket) using the `mknod` syscall (see man pages). And that is supported in the 17074 Insider build. What is not yet supported is using the socket API’s to create unix socket in DrvFS. Follow the blog post on AF_UNIX on Windows for any updates on that https://blogs.msdn.microsoft.com/commandline/2017/12/19/af_unix-comes-to-windows/

  4. L. says:

    Would it be possible to have finer control on this feature, e.g. use “-o metadata=fifo,sockets” to have support for fifo and sockets but neither devices nor unix permissions?
    Regarding security, these unix permissions can always be bypassed by invoking a windows executable, don’t they? i.e. the only relevant data security-wise is the ACL.
    Does it work on network drives (Windows shares, and, if you have tested, with Samba)?

  5. dudu says:

    what about nfs support?

  6. Ivy Johnson says:

    I keep getting the error:
    User@DESKTOP-DR9U1BI:/mnt/c/Windows/System32$ sudo mount -t drvfs C: /mnt/c -o metadata
    mount: C: is already mounted or /mnt/c busy
    C: is already mounted on /mnt/c
    And all the fixes out there are for Linux, do you have a WSL workaround?

    1. Did you make sure to unmount C: before remounting with metadata? See the top of the post — “sudo umount /mnt/c”

      1. Ivy Johnson says:

        Right, sorry, forgot to say in the initial comment that when I attempt to unmount I get:
        umount: /mnt/c: target is busy
        (In some cases useful info about processes that
        use the device is found by lsof(8) or fuser(1).)

        1. Andrew says:

          I get the same

        2. John Doe says:

          You must make the current directory of bash outside of /mnt/c.

  7. Dominik Fiala says:

    This release made my day! I was struggling tryng to SSH to my Vagrant machine running in WSL, but the connection was denied due to shared private key file. Finally I can chmod the private key file! Great work guys! Also really looking forward to making this option persistent, so far I need to script it.

Skip to main content