I’m on Ubuntu 20.04. Jupyter notebook was installed with:
pip3 install notebook
When I try to load any of my notebooks, “NotebookApp” seems to crash with the following message:
PermissionError: [Errno 13] Permission denied: ‘/usr/local/share/jupyter/nbconvert/templates/conf.json’
I do see in google discussions on this error, but they all seem to point to nbconvert 6.1.0, while my current version is ‘Jupyter Notebook 6.4.8’.
nbconvert is a separately installable (and maintained) project that is installed when notebook is installed so it has its own version information. Although pip list or pip freeze will indicate its version, a quick way to summarize the commonly-used Jupyter packages is to simply run jupyter --version. You should find nbconvert listed in that output.
As for the actual issue, if this is truly a shared environment/filesystem the permissions on ‘/usr/local/share/jupyter/nbconvert/templates/conf.json’ may need to be relaxed - but that may be the subject of the google discussions you’ve encountered.
No, this is just a personal use system. However, there is the root account and the user account. I’m not generally logged in as root.
The pip installs are done from the user account only.
I had no problems with my earlier ubuntu 16.04, which had the same account setup - jupyter notebook et all worked fine once installed without the need to tweak permissions. I suppose a lot of people will run it to this, since this is the behavior straight out of the box in ubuntu 20.04.
No, this is just a personal use system. However, there is the root account and the user account. I’m not generally logged in as root.
Ok. Check the permissions on the file and adjust them accordingly. It sounds like that file may have been produced from the root account or something else is going on. What do the google discussions say? Can you provide a link?
What do these produce: ls -l /usr/local/share/jupyter/nbconvert/templates/conf.json ls -ld /usr/local/share/jupyter/nbconvert/templates
Thanks Felix. This is an nbconvert issue and directly related to the second issue you linked (the first issue eventually collapses into the second).
Since root is the only user allowed to do anything in the templates directory, your regular user doesn’t have permission to add/remove files in that directory. You might try changing the templates directory owner to your user-id, although there may be other restrictions in the parent directories above templates. I also don’t know nbconvert that well and the best way to resolve this particular snafu. These are the kinds of things where you may have installed things using root, then run into issues attempting to use those packages and everything gets wrapped around the axle.
One approach would likely be to downgrade nbconvert to 5.6.1, but downgrading should be a last resort as it really doesn’t resolve the core issue here and will pollute the site-packages. I would first try changing the ownership of the templates directory and any files it might contain, but you should also look at its parent and grandparent directories.
Since it seems like @jasongrout was active on these issue threads, I’m hoping he might have ideas on the best path forward. You could also try opening an issue in https://github.com/jupyter/nbconvert/issues or comment on the existing issue.
I can confirm that all pip modules I’ve installed are never from root in ubuntu 20.04. (Don’t exactly remember if I had ever installed them from root in earlier versions of ubuntu 16.04 or 18.04 - these installation even if done would have gone into their particular python environments… but then this isolation doesn’t work for system directories).
Anyway, based on what I read in the second issue - my understanding is that the piece of code being discussed ended up creating directories where it was meant only to check if they already existed. This code was fixed in later versions. The version I have has the fix. So I suspect somehwere in my migration from 16.04 to 20.04, I’d probably have executed a version of the module that had this bug and thus ended up creating those directories. Since the current version is a fixed version, I am assuming that it reverts to just checking for the presence of those directories. Under normal circumstances these directories should not have existed in my installation, except for an execution of a prior buggy version - but that means even though the fix is there in my current version - the directories created by the earlier buggy versions still remains in my system - so when the corrected version goes looking for those directories it finds a match - so probably goes into paths not intended.
So I simulated a removal of those directories by renaming /usr/share/jupyter and /usr/local/share/jupyter to a different name. Then brought up the notebook again and everything seems to be well.
Awesome! Yeah, I figured that (part of my axle comment), and just removing the directory rather than trying to track it down seems like a better approach anyway. Since you renamed the parent directories, you may need to reinstall kernelspecs (or copy the subdirectories back to their expected locations) if they were installed there in the first place.
Depending on how they’re installed, the kernel specifications (“kernelspecs”) can reside in /usr/local/share/jupyter/kernels. Since you had removed /usr/local/share/jupyter, then any kernelspecs under that directory would require their reinstallation. If things are working with respect to kernels - then you’re fine. The symptom would be that a kernel tile (if using Lab) or an option in the kernel dropdown (if using Notebook) that was present before would be missing now.
I believe you’re good to go at this point - happy computing!