Well, I have a WSL2 with Ubuntu 20.04.3 LTS on it. It is intended for web-development purposes, so nginx, php and other related apps are installed there. No GUI.

So when I start it with wsl from Windows PowerShell, I always have to go to the project root and set correct folder permissions:

sudo chown -R $USER:www-data /var/www/html/project_root/all_required_folders

It works fine until I restart WSL, then after boot, permissions are being reset back and I have to set them once again.

I know that I can add these commands to run after boot, but I am curious about the reason, because I did not experienced this before (unless I moved to clean system from HDD to SSD, but I don't think this might be the reason).

Honestly, I don't think this issue comes from nginx, I guess somewhere esle?

Have to note, that not all folder group is being reset, only some of them, somehow. And these are usually /node_modules, /storage and /bootstrap (Yes, I'm running Laravel).

So, why this happens? It does not reset folder permissions - only owner & group.

2 Answers 2


From Stack Overflow:

To enable changing file owners & permissions, you need to edit /etc/wsl.conf and insert the below config options:

options = "metadata" 

This may require restarting WSL (such as with wsl --shutdown) or the host machine to take effect. This has been possible since 2018.

Please visit the link above for the full answer plus the two other answers which you may prefer.

Also consider new method announced by Microsoft in 2018. This method goes into even more depth and involves the mount command.

  • Pretty sure that's not the issue here (although that's always the first suspect). If it were, the chown wouldn't even work at all. It would return successfully, but the ownership would still be the same. In this case, the OP specifically says "It works fine until I restart WSL", so changing the permissions is working. Also, the OP says that permissions are not being reset, so that also says it's not the metadata. And finally, metadata is only applicable to files on Windows mounts -- Unless the path listed in the question includes a symlink, that doesn't appear to be the case here. Nov 21, 2021 at 21:59
  • @NotTheDr01ds If OP accepts your answer kindly remind me to delete mine. Thanks :) Nov 22, 2021 at 0:09

Usually we do suspect the metadata support for drvfs filesystems when this type of "permissions or ownership" issue occurs (as noted in the existing answer).

However, in this case I don't believe that's what you are seeing, for multiple reasons:

  • First, the metadata option is only applicable to Windows drive mounts. Unless there's a symlink in your /var/www/... path that you didn't mention, that doesn't appear to be the case here.

  • But more than that, if that's the problem you were having, then chown wouldn't work at all. Without metadata support, the files and directories on the Windows drive are always owned by the default user. A chown would simply have no effect.

  • And you mention that permissions are not reset, so I'm assuming you have been able to set some non-default permissions. This also wouldn't be possible on a Windows drive without the metadata option.

So with that ruled out (I believe), I'd look at two other possible culprits:

  • My next "normal" suspicion (if this wasn't a web app) would be something in your shell startup. However, I don't see that being the case here. It's easy to eliminate startup config by running with wsl -e bash --noprofile --norc if you'd like to test it.

  • But what I really think you are seeing here is something like this. It's really "normal behavior" -- The web-server, running as www-data, is creating files/directories. These files are naturally owned by the user/process that created them. I don't think that ownership is being reset when WSL restarts. I think they are just being written with that ownership in the first place.

    If that's causing issues for your development, then add your user to the www-data group with sudo usermod -aG www-data $USER. Or see the linked answer for additional options.

  • Thank you for your anwer! Yes, you are correct: there is no any symlink in /var/www, as well as I've been able to set permissions that I need for Laravel. I already added $USER to www-data as you said, just didn't mention it in my question (sorry for that). Definitely will take a look on your mentioned answer, thanks for that! Just curiosity that made me question the reason of that issue.
    – Max Krizh
    Nov 22, 2021 at 2:57

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .