notebook: PermissionError: [Errno 13] Permission denied

I had the same issue, reinstalled Anaconda but it was not working.

The solution that worked for me was extremely simple.

I ran Anaconda + Jupyter as administrator and it was solved.

Solution till the PR is merged to master:

- user, _domain, _type = win32security.LookupAccountName("", win32api.GetUserName())
+ user, _domain, _type = win32security.LookupAccountName("", win32api.GetUserNameEx(win32api.NameSamCompatible))

Does fix it for me… Windows users can fix it easily with the following steps:

1. delete the existing kernels and files (save the content of your notebook_cookie_secret if you have many links pointing to it)
2. edit C:\Users\{USERNAME}\AppData\Local\Programs\Python\Python{Version}\site-packages\jupyter_client\connect.py
3. replace the line 59 with the proposal made by @kevin-bates 
4. delete the corresponding compiled python file (C:\Users\mike\AppData\Local\Programs\Python\Python37\Lib\site-packages\jupyter_client\__pycache__\connect.cpython-XX.pyc)
5. Enjoy all notebooks working again...

@snapo - thank you so much (yet again)! @alexbaharov - I wonder if you’re hitting the pywin32==225 issue that exists on conda? That said, I don’t know why updating the code would work for you - unless in the process of reverting the modules, you also reverted pywin32 to 224.

Because @snapo was successful and @MSeal did testing as well I think I’m going to move forward with the library dependency updates in Notebook.

We can continue to use this issue to understand @alexbaharov’s issue, if that works for others. You might try performing the updates and ensuring you’re running pywin32==224.

@snapo - thank you so much for your help! This information has been useful. Others that have access to Windows systems may be able to look into this deeper as well (I don’t have such access unfortunately).

Sorry for taking your time. Its just that its difficult to get good diagnostic information so I tried to gather what I thought might be helpful - thank you again! Have a great weekend!

If downgrading works, then JUPYTER_ALLOW_INSECURE_WRITES=1 env variable should also work. All that changed was a check that your permissions are actually being set for secret files. The ways this can fail to write is A) your filesystem is mounted on a system that doesn’t support full permissioning (e.g. some docker setups or network harddrive protocols), or B) your directory path is owned or restricted by the Admistrator/root somewhere up the line of directories, preventing your user from assigning permissions.

There’s a new flag now with jupyter_core 4.6.3, where if you set the environment variable JUPYTER_ALLOW_INSECURE_WRITES to 1 or true it will disable the secure write checks. You’ll get a warning instead of an error for permission issues. This isn’t recommended by default, and it’s better if you have jupyter shared files in a folder where you can control permissions (kernel hijacking is possible with this information saved there), but if you have no control and the mounted OS has no permission settings available the env variable should opt you back to the pre-secure-write behavior.

Heya @kevin-bates ,

1. Yes now the SID resolves to the correct one and yes it is human readable as it can now be resolved.

2. Regarding this part that would be my first PR for a public project ;=) have to first read on the guidelines on how to do that properly. Personally im not about getting points and its only 1 line change. So if you like you can catch it. What i can not do is test it if it is still working on all Windows OS versions (backtest) , corporate domain joined pc’s work too as i tested it in the company i work with too. There fore i cant gurantee it will fix all error 13’s but mine is working and also that i tested it on a corporate ad joined pc, and on a workgroup joined pc without a windows live id.

Best regards Mike

Hi, I just created today a new kernel in Windows (native not WSL) and all my notebooks stopped working with the Error 13 Access Denied.

        with os.fdopen(os.open(fname, open_flag, 0o600), mode) as f:
    PermissionError: [Errno 13] Permission denied: 'C:\\Users\\mike\\AppData\\Roaming\\jupyter\\runtime\\kernel-41bd85f6-1192-4a91-b5bf-9cc4c94c1500.json'
[W 20:18:50.432 NotebookApp] Unhandled error
[E 20:18:50.435 NotebookApp] {

After that i checked with dir the mode permissions:

Mode                LastWriteTime         Length Name
----                -------------         ------ ----
-a----        9/27/2019   7:49 PM              0 kernel-0ea79e39-5e76-44dc-a001-05dc73f866ef.json
-a----        8/29/2019  12:33 AM            274 kernel-12d7f348-0baa-4fce-8c85-752390e405eb.json
-a----        9/24/2019   6:15 PM            274 kernel-2aca9f02-16b9-46b0-b80a-ff805bf541f6.json
-a----         8/3/2019   9:56 PM            274 kernel-319e4df2-c173-4e43-bcec-76e72d9add81.json
-a----        9/21/2019  10:38 PM            274 kernel-3422b12a-dc24-4f1b-838b-5fcfa8ae3d29.json

with get-acl i listed the acl for the current folder and also for the specific folder which i use:

PS C:\Users\mike\AppData\Roaming\jupyter\runtime> get-acl


    Directory: C:\Users\mike\AppData\Roaming\jupyter


Path    Owner     Access
----    -----     ------
runtime MIKE\mike NT AUTHORITY\SYSTEM Allow  FullControl...


PS C:\Users\mike\AppData\Roaming\jupyter\runtime> get-acl C:\\Users\\mike\\AppData\\Roaming\\jupyter\\runtime\\kernel-41bd85f6-1192-4a91-b5bf-9cc4c94c1500.json


    Directory: C:\Users\mike\AppData\Roaming\jupyter\runtime


Path                                             Owner     Access
----                                             -----     ------
kernel-41bd85f6-1192-4a91-b5bf-9cc4c94c1500.json MIKE\mike BUILTIN\Administrators Allow  FullControl...

my user mike is in the local administrator group, but i start the notebook always as user (never as administrator). Additionally i create with the following script my virtual environments:

@echo off
set /p id="Enter Project Name: "

mkdir "%~dp0%id%"
mkdir "%~dp0%id%\data"
mkdir "%~dp0%id%\docs"
mkdir "%~dp0%id%\src"
mkdir "%~dp0%id%\test"

cd "%~dp0%id%"
python -m venv project
cd "%~dp0%id%\project\Scripts\"
start "%id% Python" activate.bat

cd "%~dp0"

echo Copy paste the parseinpythonshell.txt to the python shell that opens from the virtualenv
@pause

echo python -m pip install --upgrade pip > "%~dp0%parseinpythonshell.txt"
echo pip install ipykernel >> "%~dp0%parseinpythonshell.txt"
echo ipython kernel install --user --name=%id% >> "%~dp0%parseinpythonshell.txt"

So it shouldnt be possible that i created a virtual env somehow that could destroy the system.

Any input on what else i can check to remove this error would be helpful…

the simplest solution on this topic is to run anaconda prompt as administrator

@kevin-bates, you now have triage permission to be able to manage issues. Congratulations and thanks! 😃

Hi @Vermilion69.

As of last week, those steps aren’t necessary provided you have jupyter_client 5.3.4 and jupyter_core 4.6.0 installed. Right around this same time, Windows issues were exacerbated with a conda-related snafu with the 225 build of pywin32.

Please ensure the versions of jupyter_client and jupyter_core are correct, check the version of pywin32 and restart your Notebook server. If you reproduce the issue, we should probably confirm it’s the same instance of this issue (there are several surrounding this area of code lately) - so providing the console update of the traceback would be helpful. I would also recommend you add the --debug flag when restarting your Notebook server - so we get as much information as possible.

If things are getting too tight for your project tomorrow, I suspect you’ll find downgrading jupyter_client to 5.3.1 to be a workaround, but just keep in mind that your connection files (and some others) are not as secure as they should be - thus the scramble to get these pieces fixed up.

@kevin-bates yes sure… will do the test today evening, will get back asap with the results 😃

@snapo - now that jupyter_client and jupyter_core releases have been made available (and contain the fix for this issue), would you mind trying the following…

1. pip install jupyter_client --upgrade - this should replace your modified jupyter_client package with release 5.3.4 and install the updated version of jupyter_core (4.6.0)
2. If you find that jupyter_core is NOT 4.6.0 - please try pip install jupyter_core --upgrade.

you’ll also notice that the change you made in jupyter_client is not present as it is now located in jupyter_core.

I will be updating the Notebook dependencies to these versions, but thought it might be a good idea to check this out somewhere and, well, you’ve been extremely helpful in this effort. 😄

@kevin-bates 6347922+snapo@users.noreply.github.com is the mail i generated (no-reply) mail best regards

@kevin-bates absolutely no problem i like to help as im also using the product and i like it quite a lot. I additionally learned a lot more about jupyters notebook and also the standard virtualenv from python ;=)

Finally i found which file is responsible and from where to where connections and requests are going.

First of all your proposal of:

- user, _domain, _type = win32security.LookupAccountName("", win32api.GetUserName())
+ user, _domain, _type = win32security.LookupAccountName("", win32api.GetUserNameEx(win32api.NameSamCompatible))

Does fix it for me… Windows users can fix it easily with the following steps:

1. delete the existing kernels and files (save the content of your notebook_cookie_secret if you have many links pointing to it)
2. edit C:\Users\{USERNAME}\AppData\Local\Programs\Python\Python{Version}\site-packages\jupyter_client\connect.py
3. replace the line 59 with the proposal made by @kevin-bates 
4. delete the corresponding compiled python file (C:\Users\mike\AppData\Local\Programs\Python\Python37\Lib\site-packages\jupyter_client\__pycache__\connect.cpython-XX.pyc)
5. Enjoy all notebooks working again...

What i am not so happy about is the data structure and paths used on Windows 😦

Applications should stay in *C:\program files* but python is in C:\Users\mike\AppData\Local\Programs Application data (programdata) should be in C:\ProgramData but they are in C:\Users\mike\AppData\Roaming

Thank you very much again for your absolutely great work in supporting jupyter notebook. I would never have been able to find that out by my own. Finally i can go forward working with my notebooks 😃

Virtualenvs get the recompiled pyc files from python directly ;=) thats why i was a bit off the shoes in understanding that…

Just out of curiosity - can you change the call from win32api.GetUserName() to win32api.GetUserNameEx(win32api.NameSamCompatible)? Not sure that will even run, but it looks correct.

Hi @Srikanth-Kb - sorry for this inconvenience.

This is the same issue as described here https://github.com/jupyter/jupyter_client/issues/479, but it sounds like you might be at more liberty to share information (which may prove useful).

Could you please provide the following…

1. Is the user running the notebook server (presumably srikanth) a member of the Windows Administrators group?
2. Any additional information about the file C:\Users\srikanth\AppData\Roaming\jupyter\runtime\kernel-026a1895-5304-47b1-b096-7c7c0c165723.json would be helpful. DIR, ls -l - whatever filesystem stat information you can provide about the file.
3. A screen shot (or equivalent) of the Security tab via the Windows explorer relative to that file?

I’m beginning to wonder if the step that secures the file using Windows privs is side-affecting things when the user is not in Administrators by replacing the CREATOR OWNER ACE when constructing a new ACL.

As many details as you can provide regarding the file would be much appreciated. Thank you.