search

nullpo-head / WSL-Hello-sudo

Let's sudo by face recognition of Windows Hello on Windows Subsystem for Linux (WSL). It runs on both WSL 1 and WSL 2. This is a PAM module for Linux on WSL.
MIT License
1.22k stars 46 forks source link

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 2 years ago

mjkl-gh commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

@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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

@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 commented 2 years ago

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 commented 1 year ago

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 commented 1 year ago

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.