## 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.

```text
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