"Permission Denied" trying to run Python on Windows 10

Question

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?

Probably worth checking the Microsoft website. I read somewhere, sorry can't remember where, that other people were having problems with this update - blank screen I think. Anyway, waiting until they fix it in a day or two might turn out to be the answer. — Ant, Jul 10 '19 at 16:39
BTW, "permissions on python are '-rwxr-xr-x'" is probably meaningless in Windows. That's something fake reported by a Unix-like environment such as MSYS2 or git-bash. — Eryk Sun, Jul 11 '19 at 04:34
Nope. This is the Python package from python.org. Same on that's been working for years without any issue and just started acting up with the latest Windows patch. — notanumber, Jul 12 '19 at 16:25
Unfortunately, no. I've been living with it as I do most of my work in Docker. If I do, I'll be sure to post my findings! — notanumber, Jul 22 '19 at 19:15
See also https://superuser.com/a/1576801/93082 solution #1 `mklink \Python39\python3.exe \Python39\python.exe` — MarkHu, Dec 19 '20 at 00:43

score 260 · Accepted Answer · edited Jun 06 '20 at 15:27

260

As far as I can tell, this was caused by a conflict with the version of Python 3.7 that was recently added into the Windows Store. It looks like this added two "stubs" called python.exe and python3.exe into the %USERPROFILE%\AppData\Local\Microsoft\WindowsApps folder, and in my case, this was inserted before my existing Python executable's entry in the PATH.

Moving this entry below the correct Python folder (partially) corrected the issue.

The second part of correcting it is to type manage app execution aliases into the Windows search prompt and disable the store versions of Python altogether.

It's possible that you'll only need to do the second part, but on my system I made both changes and everything is back to normal now.

edited Jun 06 '20 at 15:27

KyleMit

45,382
53
367
544

answered Jul 23 '19 at 16:03

notanumber

5,041
3
18
28

I have in my local user's path variable two references to this same folder, one with a literal path, the other with a relative path: `C:\Users\blah\AppData\Local\Microsoft\WindowsApps` is the 4th entry, and `%USERPROFILE%\AppData\Local\Microsoft\WindowsApps` is the last entry in the list. -- On the other hand, my *system* path variable contains no reference to the WindowsApps folder at all. Additionally, neither one of these contains a reference to any other Python paths. – Ryan Aug 11 '19 at 05:57
67

(Microsoft employee and CPython core developer here) You definitely only need to do the second part. There have been a couple of bugs related to upgrading apps resetting aliases which will be fixed in the next stable update, so it should be a one-time fix by then. While you're getting Insiders updates you may need to do it a couple more times. – Zooba Aug 12 '19 at 02:14
11

Also, the "Access Denied" issue is a Git Bash bug (or whoever maintains their Bash port... I'm not sure myself whose it is). And launching the Store is a new feature to help people install Python - if you've added it to PATH using the regular installer it should take precedence over the new redirector, but if not you've discovered above how to disable it. – Zooba Aug 12 '19 at 02:24
(To clarify my own comment - "if you've added it [Python, not the Store launcher] to PATH using the regular installer...") – Zooba Aug 12 '19 at 15:25
5

I just had to to the second part to fix this problem for me. – kennyB Oct 02 '19 at 09:10
7

For me I had to also add python to my path (C:\Users\YourUsernameHere\AppData\Local\Programs\Python\Python37) for git bash to find python – Niels Oct 08 '19 at 12:12
I never did anything with the winsows store regarding Python. Python is also not listet in 'App execution aliases'. – ThaJay Nov 28 '19 at 15:16
2

Adding it to my my path and moving it to the top was my solution, just like Neils did. The fact that I can't just rename the stub for the windows store stub is pretty annoying. – John W. Clark Dec 07 '19 at 14:51
Thank you so much this help me solve my problem running flask from cmd (python) – TheCodeLearner Jun 29 '20 at 16:35
1

doing just the second part crashes git bash on startup with a "There are no available terminal" error. this kind of insanity makes dual-booting and dealing with windows 10's chronic inability to share a system nicely look inviting – worc Dec 05 '20 at 06:50
Just in case it helps.. I got this to work very simply by doing alias python='winpty python.exe' on the command line in git bash... On Windows 10 and after doing parts 1 and 2 above... – Vida Dec 16 '20 at 21:35
2nd part worked for me too. – AidanGawronski Dec 21 '20 at 20:20
1

For me, the problem was that python was moved to C:\Program Files\WindowsApps\PythonSoftwareFoundation.Python.3.8_3.8.1776.0_x64__qbz5n2kfra8p0\python3.8 instead of the default path. I removed all paths both from sublime and env variables, reinstalled, added new paths and now it works. The only problem is that it's a clean install and I have to reinstall all dependencies – Rares-Adrian Mosescu Jan 16 '21 at 09:22
1

What a complete waste of humanity's time. Whichever parties conspired to make this be the case need to seriously consider their career choices. Thanks for the fixes – Andrew Bullock Jan 21 '21 at 19:24
You're a life saver, and what the hell Microsoft ? – Fabii Mar 10 '21 at 17:54
Adding in to the path manually and disabling those aliased did it for me Python 3.9.4 – Mirza Sisic Apr 19 '21 at 12:52

Ryan · Answer 2 · 2019-08-11T07:13:41.860

27

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.

edited Aug 11 '19 at 07:13

answered Aug 11 '19 at 05:43

Ryan

1,112
2
14
25

13

(Microsoft employee and CPython core developer here) There's a bug right now I'm working on getting fixed in Windows where you can launch executables in this location but only if you have the global alias enabled (in Manage App Execution aliases). I'm trying to get it changed so that you only need to have installed the app for the current user. – Zooba Aug 12 '19 at 02:15
4

We can read the permissions via this dialog because it's owned by a dllhost.exe instance (hosting the security shell extension, rshx32.dll) that's running with administrator access and thus has "list folder contents" access (i.e. execute; sync; and read data, attributes, and permissions). The entry for the users group is not for a normal access check. It's conditional on the existence of a WIN://SYSAPPID security attribute, i.e. any app. The subfolder for each app grants read access to users, but execute access is conditional on running via the app link that sets a custom access token. – Eryk Sun Aug 12 '19 at 04:41
@ErykSun That is the first informed answer I've ever seen about windows execution and permissions. Thanks. – Ryan Aug 14 '19 at 13:00
I'm actually still dealing with the fallout from trying to change permissions on the folder. Certain WinApps stopped launching altogether, until I followed these directions: (https://superuser.com/questions/1288014/reset-default-acls-for-c-program-files-windowsapps) but now they give error messages on launching. I used an older Win10 USB image so it probably set the permissions incorrectly. – Ryan Aug 14 '19 at 13:10
This just caught me out, thanks for the good explanation. We use git bash to run shell scripts to invoke an emscripten build, and as part of the standard emscripten scripts it tries to divine your python version via $(which python) ... which immediately blows up. – Mark Simpson Jan 28 '20 at 09:07
1

@MarkSimpson glad this thread helped. Not sure what I may have written. Be sure to thank the Microsoft employees that posted real answers in the comments here. – Ryan Jan 29 '20 at 06:05
1

this bug still seems to be lurking over a year later... as far as i can tell getting GitBash, python and windows 10 to work together is still a dead end – worc Dec 05 '20 at 06:54

score 19 · Answer 3 · answered Aug 11 '19 at 14:39

19

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.

answered Aug 11 '19 at 14:39

John Fisher

199
3

I definitely have this issue running python from bash but not from powershell - however I don't think the bug you linked is the issue. Much more likely to be this: https://github.com/msys2/Msys2-packages/issues/1943 – Matthew Jan 26 '21 at 11:16
the thing is, microsoft has no right to invent new operating system features, since those would not be standard, thats something only linux/posix can do. so msys2, kudos to them for putting up with all the msft they have, and im sure theyll figure this one out too, but its not their fault its msft – Dave Ankin Feb 12 '21 at 12:59

score 18 · Answer 4 · edited Jun 06 '20 at 15:12

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:

Type environment variables in the start search bar, and open Edit the System Environment Variables.
Click Environment Variables...
In the System Variables section, locate the variable with the key Path and double click it.
Look for paths pointing to python files. Likely there are none. If there are, select and delete them.
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.
Create another variable pointing to the Scripts directory. Typically it is C:\Users\[YOUR USERNAME HERE]\AppData\Local\Programs\Python\Scripts.
Restart your terminal and try typing py, python, python3, or python.exe.

What about users who installed Python via Anaconda? I did all every step, a system variable pointing to my python installation exists in system variables and the problem still persists. — Martin, Mar 29 '21 at 13:52

score 9 · Answer 5 · answered Jul 01 '20 at 14:01

9

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.

answered Jul 01 '20 at 14:01

Shakeel

1,079
7
16

score 7 · Answer 6 · edited Jun 06 '20 at 15:23

7

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

edited Jun 06 '20 at 15:23

KyleMit

45,382
53
367
544

answered May 04 '20 at 07:48

Shirish

89
1
3

this actually worked, this is like what the hell situation. lol :D – Biskrem Muhammad Feb 16 '21 at 17:09

score 5 · Answer 7 · edited Nov 28 '19 at 17:20

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.

score 5 · Answer 8 · answered Nov 23 '20 at 07:36

5

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

answered Nov 23 '20 at 07:36

Arun

494
5
11

score 4 · Answer 9 · answered Feb 15 '21 at 09:37

4

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

answered Feb 15 '21 at 09:37

Ndatimana Gilbert

79
1
3

so that´s a new thing implemented in py 3.9.4? – dawn Apr 19 '21 at 03:49
Could anyone add more context on what is `PY` ? – secavfr May 29 '21 at 10:07

score 3 · Answer 10 · answered Nov 22 '20 at 22:29

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.

"Permission Denied" trying to run Python on Windows 10

17 Answers17

Research

Solution

Further Reading

Linked

Related