-
Notifications
You must be signed in to change notification settings - Fork 47
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
Comments
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? |
try falling back to WSL 1 and running the install script:
this could be the cause. |
Don't you have some weird 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
No, this behavior has not changed for quite some time since WSL 1 era. 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. |
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? |
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 |
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:
so i'm guessing there are no weird umask settings |
Same error after a fresh install of a default wsl on Windows 10. 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). |
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. |
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
The text was updated successfully, but these errors were encountered: