Join Log in
Score:6
avatar Ubuntu

Ubuntu 20.04 on WSL2: Folder owner & group are being reset after each start

de flag
Max Krizh

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.

823
0 + 0
Score:3
WinEunuuchs2Unix avatar Ubuntu
in flag
WinEunuuchs2Unix

From Stack Overflow:

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

[automount] 
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.

0 + 0
NotTheDr01ds avatar
vn flag
NotTheDr01ds
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.
0
Reply
WinEunuuchs2Unix avatar
in flag
WinEunuuchs2Unix
@NotTheDr01ds If OP accepts your answer kindly remind me to delete mine. Thanks :)
0
Reply
Score:3
NotTheDr01ds avatar Ubuntu
vn flag
NotTheDr01ds

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.

0 + 0
de flag
Max Krizh
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.
0
Reply
ธงชาติไทย
Elon Musk
I sit in a Tesla and translated this thread with Ai:

mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.