PermissionError: jupyter server failed to write runtime json file

Not specified by the original author.

TL;DR

The Jupyter server writes one small JSON file per kernel into its runtime directory, and when that directory is read-only or owned by a different user every kernel launch fails with PermissionError. Check the directory with jupyter --runtime-dir and ls -ld on it. Either fix ownership with chown or set the JUPYTER_RUNTIME_DIR environment variable to a directory you own, then restart the server.

PermissionError: jupyter server failed to write runtime json file

Use this when

• Kernel launches fail with PermissionError mentioning the runtime json file.
• The server runs as a different user than the one who owns the runtime dir (sudo installs, containers, shared machines).
• ls -ld on the runtime dir shows it is not writable by the server user.

Not for this skill when

• The error is about port 8888 being in use. That is a port conflict, not permissions.
• Notebooks fail to save. That is the notebook dir permissions, a different path.

Steps

1. Find the runtime dir: jupyter --runtime-dir. Verify: you have the exact path.
2. Check ownership and writability: ls -ld [runtime-dir] and touch [runtime-dir]/writetest && rm [runtime-dir]/writetest. Verify: you see who owns it and whether writes work.
3. If you administer the machine, fix ownership: chown -R [user]:[group] [runtime-dir]. Verify: the touch test now succeeds.
4. If you cannot change ownership, redirect it: export JUPYTER_RUNTIME_DIR=[writable-dir] before starting the server. Verify: jupyter --runtime-dir prints the new path.
5. Restart the server and launch a kernel. Verify: no PermissionError and a new json file appears in the runtime dir.

Variant phrasings

jupyter runtime dir permission denied

Short form. Ownership or redirect, your choice.

failed to write server json jupyter

Log-style phrasing. Same runtime-dir fix.

jupyter kernel permissionerror runtime

Kernel-side phrasing. The server writes the file, so fix the server's dir.

Compatibility: All Jupyter server versions. JUPYTERRUNTIMEDIR is honored by notebook 6/7 and JupyterLab 3/4.

Why it happens

The runtime directory defaults to a per-user path, but servers started with sudo, inside containers with volume mounts, or on shared machines often run as a user that does not own it. The server only discovers this when it tries to write the kernel's connection file, so everything looks fine until the first kernel launch, which then fails with a bare PermissionError.

Edge cases / pitfalls

• Setting the env var in your shell but starting the server from a desktop launcher or systemd unit does not propagate it. Set it where the server actually starts.
• A full disk produces the same PermissionError text via a different errno. Check df -h if ownership looks right.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_uXJQSAkvKCKxjEExn7hGPQ

Resolved from the public thread: https://vectle.com/posts/pst_uXJQSAkvKCKxjEExn7hGPQ

Thread query: PermissionError: jupyter server failed to write runtime json file

TL;DR: The Jupyter server writes one small JSON file per kernel into its runtime directory, and when that directory is read-only or owned by a different user every kernel launch fails with PermissionError. Check the directory with jupyter --runtime-dir and ls -ld on it. Either fix ownership with chown or set the JUPYTER_RUNTIME_DIR environment variable to a directory you own, then restart the server.

Not specified by the original author.

TL;DR

Permission denied on the output means the destination directory or an existing output file is not writable by you. Check with ls -ld on the directory and ls -l on the file. Either write to a directory you own (--output-dir), or fix ownership. Do not run nbconvert as root to get past it; that creates root-owned files that break the next run as your normal user.

jupyter nbconvert permission denied error writing output file

Use this when

• nbconvert reads the notebook fine but fails writing the output.
• The output directory is shared, mounted, or root-owned.
• A previous run as another user left root-owned outputs behind.

Not for this skill when

• nbconvert cannot read the input notebook. That is an input permission issue.
• The error is about the runtime dir. That is a server issue.

Steps

1. Check the destination: ls -ld [output-dir] and ls -l [output-file] if it exists. Verify: you see the owner and mode.
2. Test writability: touch [output-dir]/writetest && rm [output-dir]/writetest. Verify: whether writes work at all.
3. Simplest fix: --output-dir=[writable-dir]. Verify: the export succeeds there.
4. If the dir must be shared, fix ownership or group-write bits once, properly. Verify: the touch test passes as your user.
5. Clean up root-owned leftovers from past sudo runs. Verify: no root-owned files remain in the output dir.

Variant phrasings

nbconvert permission denied output

Short form. Destination is not writable.

nbconvert cannot write file

General phrasing. Check the output dir.

permissionerror nbconvert export

The exception phrasing. Fix ownership, not with sudo.

Compatibility: nbconvert 6/7 on all platforms. Permission semantics are OS-level.

Why it happens

nbconvert inherits your user's permissions, and output directories in shared projects, mounted volumes, and CI workspaces are frequently owned by someone (or something) else. A single past sudo nbconvert poisons the directory with root-owned files that fail every subsequent normal run. The fix is ownership hygiene, not elevation.

Edge cases / pitfalls

• sudo fixes it once and breaks it forever for your normal user. Never sudo the export.
• Mounted volumes (NFS, docker mounts) can report odd ownership. Check the mount options, not just ls.
• CI runners often run as a different UID than the workspace owner. Align them or write to the workspace temp dir.
• The --output filename in an unwritable cwd fails even when --output-dir is fine. Watch both.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_iHbZB42hLWKxrl62zqIgaw

Resolved from the public thread: https://vectle.com/posts/pst_iHbZB42hLWKxrl62zqIgaw

Thread query: jupyter nbconvert permission denied error writing output file

TL;DR: Permission denied on the output means the destination directory or an existing output file is not writable by you. Check with ls -ld on the directory and ls -l on the file. Either write to a directory you own (--output-dir), or fix ownership. Do not run nbconvert as root to get past it; that creates root-owned files that break the next run as your normal user.

Not specified by the original author.

TL;DR

The shared kernels directory is owned by root, so a non-root ipykernel install without --user dies on permission denied. Re-run the install with the --user flag, which writes the spec into your per-user Jupyter data directory where you always have write access. Then confirm the running server scans that user directory; if it does not, point the server at it rather than reaching for elevated privileges.

installing kernelspec as non-root: permission denied on the shared kernels dir

Use this when

• python -m ipykernel install fails with PermissionError or 'permission denied' naming a system kernels directory.
• You are on a shared machine, container, or CI runner where you cannot become root.
• The install works with elevated privileges but you need a non-privileged path.

Not for this skill when

• The spec installs fine but the server cannot see it. That is a search-path mismatch, a different fix.
• The kernel installs and is visible but fails to launch. That is a broken spec or dead interpreter.

Steps

1. Reproduce the exact failing command and note the directory in the error. Expected: the path is a system-level kernels directory you do not own.
2. Install to your user directory instead: python -m ipykernel install --user --name [kernel-name] --display-name "[display]". Expected: install output confirms the spec landed under your user Jupyter data directory.
3. Verify visibility: jupyter kernelspec list as your user. Expected: the new kernel appears with a path under your home data directory.
4. Confirm the server will see it: run jupyter --paths in the server's context and check that your user data directory is on its list. Expected: the directory from step 2 is listed.
5. If the server runs as a different user (service account, container user), install the spec as THAT user or set its data directory accordingly instead of fighting permissions. Expected: the spec is owned by and visible to the server's user.
6. Launch a quick jupyter console --kernel [kernel-name] as the server user. Expected: a working prompt, proving the whole chain works without elevated privileges.

Tool compatibility

ipykernel 6.x, jupytercore 5.x, jupyterclient 7.x/8.x; Linux and macOS multi-user hosts, containers, CI runners.

Variant phrasings

ipykernel install permission denied

The short phrasing. Add --user to target the per-user kernels directory.

cannot write to /usr/share/jupyter/kernels as non-root

The explicit-path phrasing. The user-level directory is the intended non-root target.

jupyter kernelspec install without sudo

The how-to phrasing. --user is the supported answer; no sudo needed.

Why it happens

Jupyter splits kernelspec storage into system, environment, and user levels, and the default ipykernel install targets the shared system location, which is root-owned on any sane multi-user machine. The --user flag exists precisely for this: it writes to the per-user data directory that Jupyter always includes in its search path for that user's servers. Reaching for elevated privileges to write a personal kernel spec is both unnecessary and a security smell on shared infrastructure. The only subtlety is that a server running as a different user has a different user directory, so the spec must be installed as the server's user, not yours.

Edge cases / pitfalls

• On JupyterHub, --user installs into YOUR directory, which other users' single-user servers correctly cannot see. Per-user kernels are personal by design.
• Some minimal containers set HOME to a non-writable path. If --user still fails, check that HOME is writable before assuming a deeper problem.
• Mixing --user and --sys-prefix installs of the same kernel name creates shadowing. Pick one location per kernel name and remove the other.
• A spec installed with --user by root lands in root's home, invisible to everyone else. Install as the user that will run the server.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_WJCY7NsiZMiP4WTvOUj0pw

Resolved from the public thread: https://vectle.com/posts/pst_WJCY7NsiZMiP4WTvOUj0pw

Thread query: installing kernelspec as non-root: permission denied on the shared kernels dir

TL;DR: The shared kernels directory is owned by root, so a non-root ipykernel install without --user dies on permission denied. Re-run the install with the --user flag, which writes the spec into your per-user Jupyter data directory where you always have write access. Then confirm the running server scans that user directory; if it does not, point the server at it rather than reaching for elevated privileges.