[python-3.x] "Permission Denied" trying to run Python on Windows 10

Seems as though an update on Windows 10 overnight broke Python. Just trying to run python --version returned a "Permission Denied" error. None of the three updates; KB4507453, KB4506991, or KB4509096 look like they'd be the culprit but the timing of the issue is suspicious. Rather than messing with rolling back, I'm hoping there's a simpler fix that I'm missing.

The permissions on python are "-rwxr-xr-x" and I haven't changed anything besides letting the Windows update reboot machine after installing last night's patches.

According to the System Information, I'm running 10.0.18362

Should also note that this is happening whether I (try) to execute Python from git-bash using "run as administrator" or not, and if I try using PowerShell, it just opens the Windows store as if the app isn't installed so I'm thinking it can't see the contents of my /c/Users/david/AppData/Local/Microsoft/WindowsApps/ folder for some reason.

I've also tried to reinstall Python 3.7.4, but that didn't help either. Is there something else I should be looking at?

It's not a solution with PowerShell, but I had the same problem except with MINGW64. I got around it by switching to Windows Subsystem for Linux (which I wanted to do anyways) as my terminal, just generally and in VSCode. This post describes it well:

How to configure VS Code (windows) to use Ubuntu App as terminal

In summary:

1) Install Ubuntu from the Windows App Store

2) Change the default bash from CMD -> wslconfig /setdefault Ubuntu

--- For VSCode

3) Restart VSCode

4) In VSCode change "terminal.integrated.shell.windows" to "C:\WINDOWS\System32\bash.exe" (for further details see the post above)

Running smoothly now in VSCode and WSL (Bash on Ubuntu on Windows). Might be at least a temporary solution for you.

Adding the Local Python Path before the WindowsApps resolved the problem.

May be you can try opening command prompt with Administrator privileges. (Run As Administrator). Works for me most of the time.

I experienced the same issue, but in addition to Python being blocked, all programs in the Scripts folder were too. The other answers about aliases, path and winpty didn't help.

I finally found that it was my antivirus (Avast) which decided overnight for some reason to just block all compiled python scripts for some reason.

The fix is fortunately easy: simply whitelist the whole Python directory. See here for a full explanation.

save you time : use wsl and vscode remote extension to properly work with python even with win10 and dont't forget virtualenv! useful https://linuxize.com/post/how-to-install-visual-studio-code-on-ubuntu-18-04/

Workaround: If you have installed python from exe follow below steps.

Step 1: Uninstall python

Step 2: Install python and check Python path check box as highlighted in below screentshot(yellow).

This solved me the problem.

This issue is far too common to still be persistent. And most answers and instructions fail to address it. Here's what to do on Windows 10:

1. Type environment variables in the start search bar, and open Edit the System Environment Variables.

2. Click Environment Variables...

3. In the System Variables section, locate the variable with the key Path and double click it.

4. Look for paths pointing to python files. Likely there are none. If there are, select and delete them.

5. Create a new variable set to the path to your python executable. Normally this is C:\Users\[YOUR USERNAME HERE]\AppData\Local\Programs\Python\Python38. Ensure this by checking via your File Explorer.

   Note: If you can't see AppData, it's because you've not enabled viewing of hidden items: click the View tab and tick the Hidden Items checkbox.

6. Create another variable pointing to the Scripts directory. Typically it is C:\Users\[YOUR USERNAME HERE]\AppData\Local\Programs\Python\Scripts.

7. Restart your terminal and try typing py, python, python3, or python.exe.

Simple answer: replace python with PY everything will work as expected

The simplest thing to do would be to modify your PATH and PYTHONPATH environmental variables to make sure that the folder containing the proper python binaries are searched befor the local WindowsApp folder. You can access the environmental variables by opening up the control panel and searching for "env"

This is due to the way Windows App Execution Aliases work in Git-Bash.

It is a known issue in MSYS2 failing to access Windows reparse points with IO_REPARSE_TAG_APPEXECLINK

As a workaround, you can alias to a function invocation that uses cmd.exe under the hood.

Add the following to your ~/.bashrc file::

function python { cmd.exe /c "python $1 $2 $3";}

For python, I'd recommend just toggling off app execution aliases as in the accepted answer, but for libraries that are distributed exclusively through the windows store like winget, this is your best option.

Further Reading

• bash: Local/Microsoft/WindowsApps/python3: Permission denied
• Permission Denied when running from bash
• winget does not run in WSL2 due to exec format error #234

For me, I tried manage app execution aliases and got an error that python3 is not a command so for that, I used py instead of python3 and it worked

I don't know why this is happening but It worked for me

I had this to Run /execute but was not working

python3 -m http.server 8080

after reading and trying some of the solutions above and did not worked , what worked for me was

python -m http.server 8080

Add the path of python folder in environmental variable and it will work

1.search environmental variable

2.look for system variable section and find variable named path in it

3.double click on path and add new path which directs towards python folder and that's it.

the python folder is usually in C:\Users["user name"]\AppData\Local\Programs\Python\Python39

This appears to be a limitation in git-bash. The recommendation to use winpty python.exe worked for me. See Python not working in the command line of git bash for additional information.

Research

All of the files in %USERPROFILE%\AppData\Local\Microsoft\WindowsApps are placeholders that point to files that are actually located somewhere in C:\Program Files\WindowsApps, which happens to be denied permissions completely.

It appears I was on the right track with my statement made in my duplicate of this problem:

"Seems like they didn't really think about the distribution method screwing with permissions!"

Source: Cannot install pylint in Git Bash on Windows (Windows Store)

Permissions are screwed up royally because of the WindowsApps distribution method:

Interestingly it says that the "Users" group can read and execute files, as well as my specific user, but the Administrators group can only List folder contents for some hilariously unfathomable reason. And when trying to access the folder in File Explorer, it refuses to even show the folder contents, so there's something fishy about that as well.

Interestingly, even though executing python in CMD works just fine, the "WindowsApps" folder does not show up when listing the files in the directory it resides in, and attempting to navigate into the folder generates a "Permission denied" error:

Attempting to change the permissions requires changing the owner first, so I changed the owner to the Administrators group. After that, I attempted to change the permissions for the Administrators group to include Full control, but it was unable to change this, because "access was denied" (duh, Micro$ucks, that's what we're trying to change!).

This permission error happened for so many files that I used Alt+C to quickly click "Continue" on repeat messages, but this still took too long, so I canceled the process, resulting in this warning message popping up:

And now I am unable to set the TrustedInstaller user back as the owner of the WindowsApps folder, because it doesn't show up in the list of Users/Groups/Built-in security principles/Other objects. *

*Actually, according to this tutorial, you can swap the owner back to TrustedInstaller by typing NT Service\TrustedInstaller into the object name text box.

Solution

There is no solution. Basically, we are completely screwed. Classy move, Microsoft.