Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

chmod: changing permissions of '/mnt/c/Users/<local_user>/AppData/Local/Programs/wsl-hello-sudo/WindowsHelloBridge.exe': Operation not permitted #30

Open
mjkl-gh opened this issue Dec 28, 2021 · 9 comments · May be fixed by #35 or #58

Comments

@mjkl-gh
Copy link

mjkl-gh commented Dec 28, 2021

As the title states, running the script generates a permission error for chmod,

Choosing a different location inside the local users folder generates the same error

Running the script with sudo stops the script asking you to run it as a local user.

Tried opening Ubuntu normally and with administrative privileges inside windows

Any idea what could cause this?

running the chmod command with sudo does work after the script failed. However, restarting the script re-executes the copy and the chmod command causing it to fail again

@mjkl-gh
Copy link
Author

mjkl-gh commented Dec 28, 2021

Also tried chown before copying manually. As soon as something is copied to the mounted c folder, the owner gets changed to root:root, maybe microsoft changed something with mountin the c drive inside wsl?

@BrendanTCC
Copy link

try falling back to WSL 1 and running the install script:

wsl --set-default-version 1 at a cmd/powershell prompt

maybe microsoft changed something with mountin the c drive inside wsl?

this could be the cause.

@nullpo-head
Copy link
Owner

@mjkl-gh

As soon as something is copied to the mounted c folder, the owner gets changed to root:root

Don't you have some weird umask settings in your /etc/wsl.conf which sets the owner of Windows files to root? Remove that settings from your /etc/wsl.conf or rewrite it so that the default owner of Windows files become your default Linux user.

Here is the official Microsoft's doc. https://docs.microsoft.com/en-us/windows/wsl/wsl-config#:~:text=options%20%3D%20%22metadata%2Cuid%3D1003%2Cgid%3D1003%2Cumask%3D077%2Cfmask%3D11%2Ccase%3Doff%22

maybe microsoft changed something with mountin the c drive inside wsl?

No, this behavior has not changed for quite some time since WSL 1 era.

@BrendanTCC

Hi, thanks for sharing your experience to the community! However, I don't think changing the default WSL version to 1 doesn't solve the problem. Setting the default WSL version only affects new distros which will be created in the future, so it doesn't the existing distros anyway.

@BrendanTCC
Copy link

However, I don't think changing the default WSL version to 1 doesn't solve the problem.

Thanks for your reply.

I did this in a fresh Ubuntu 20.04 WSL setup, upgraded to WSL 2 (where the install failed due to file permission problems), then downgraded back to WSL1 where it somehow... resolved it?

@BrendanTCC
Copy link

in any case, I found that it somehow worked, and if it does for others, great! if not, yeah ok maybe go check wsl.conf

@mjkl-gh mjkl-gh linked a pull request Jan 15, 2022 that will close this issue
@mjkl-gh
Copy link
Author

mjkl-gh commented Jan 15, 2022

@mjkl-gh

As soon as something is copied to the mounted c folder, the owner gets changed to root:root

Don't you have some weird umask settings in your /etc/wsl.conf which sets the owner of Windows files to root? Remove that settings from your /etc/wsl.conf or rewrite it so that the default owner of Windows files become your default Linux user.

Here is the official Microsoft's doc. https://docs.microsoft.com/en-us/windows/wsl/wsl-config#:~:text=options%20%3D%20%22metadata%2Cuid%3D1003%2Cgid%3D1003%2Cumask%3D077%2Cfmask%3D11%2Ccase%3Doff%22

maybe microsoft changed something with mountin the c drive inside wsl?

No, this behavior has not changed for quite some time since WSL 1 era.

@BrendanTCC

Hi, thanks for sharing your experience to the community! However, I don't think changing the default WSL version to 1 doesn't solve the problem. Setting the default WSL version only affects new distros which will be created in the future, so it doesn't the existing distros anyway.

Tried it on a fresh windows install, which is managed by IT through the domain, but came without wsl. So if there are weird settings, they came by default

Anyhow, I managed to solve the problem by changing the install script to chmod +x before moving the file. Maybe I am running a weird install, but the change is so small I opened a pull request for it.

cat /etc/wsl.conf returns:

cat: /etc/wsl.conf: No such file or directory

so i'm guessing there are no weird umask settings

@solostaran
Copy link

Same error after a fresh install of a default wsl on Windows 10.
I just "sudo apt update" and "sudo apt upgrade", restarted Windows and the "install.sh" script worked.

I forced "wsl --set-default-version 2" at the same time, but it was already showing distro with v2 (with "wsl -l -v" in powershell).
So I don't know if it changes anything.

@piotrmocko
Copy link

I had the same issue with a fresh Windows 10 Pro and WSL2 and Ubuntu 22 installation. Updating all packages on my Ubuntu and restarting Windows helped

@RihanArfan
Copy link

I had the same issue with a fresh Windows 10 Pro and WSL2 and Ubuntu 22 installation. Updating all packages on my Ubuntu and restarting Windows helped

+1 exact same scenario and fix. Freshly installed Ubuntu 22.04 on Windows 10 enterprise. After updating packages, the script failed but I hadn't restarted the PC since the Ubuntu install. After restarting, everything worked fine.

No need to downgrade and upgrade to WSL 1 and back to WSL 2.

@evanphilip evanphilip linked a pull request May 21, 2023 that will close this issue
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
6 participants