90%的permissionerror [errno 13] permission denied源于权限配置问题，而非jupyter故障；常见于windows的appdata oamingjupyter untime、linux/macos的~/.jupyter/runtime或当前工作目录，主因是用户无写入权限、文件被占用、归属错误或安全策略限制，解决需精准修复目录归属与权限，而非暴力chmod。
直接说结论：90% 的 PermissionError: [Errno 13] Permission denied 不是 Jupyter 本身坏了，而是它试图读写某个目录时被 Windows 或 Linux 的权限机制拦住了——常见位置就三个：~/.jupyter/runtime/（Linux/macOS）、C:Users{用户名}AppDataRoamingjupyter
untime（Windows）、或你当前启动 Jupyter 的工作目录（比如空文件夹、系统路径、挂载盘根目录）。
为什么 runtime 目录总报 Permission denied
Jupyter 启动后会在 runtime 目录下生成 jpserver-*.json 和 jpserver-*-open.html 这类临时状态文件。如果该目录归属用户不对、被其他进程锁住、或安全策略限制（如企业域控策略），就会触发 Permission denied。
- Windows 上最常见：目录在
AppDataRoamingjupyter untime，但当前用户没“写入”权限（尤其重装系统或切换账户后） - Linux/macOS 上可能因
chown或umask设置异常，导致~/.jupyter/runtime所属用户/组错乱 - 文件残留：上次异常退出没清理干净，新进程尝试覆盖旧
.html文件时被拒绝
解决方法不是硬 chmod 777，而是精准定位并修复归属或权限：
- 先关掉所有
jupyter notebook进程（任务管理器或ps aux | grep jupyter+kill -9） - 进到报错路径（比如
C:Usersww57AppDataRoamingjupyter untime），删掉所有jpserver-*.json和jpserver-*-open.html文件 - 右键该
runtime文件夹 → “属性” → “安全” → “编辑” → 给当前用户勾选“完全控制”，点确定 - Linux/macOS 执行：
chown -R $USER:$USER ~/.jupyter/runtime，再chmod 700 ~/.jupyter/runtime
新建 Untitled.ipynb 提示 Permission denied 怎么办
这个错误和 runtime 无关，说明 Jupyter 当前工作目录（即你点击“New”时默认保存的位置）没有写权限。典型场景：你在 C:WindowsSystem32 下启动了 Jupyter，或者用了只读挂载的网络盘、加密 U 盘、或权限受限的 Docker volume。
- 检查启动位置：终端里运行
jupyter notebook前，先pwd（Linux/macOS）或cd（Windows），确认当前路径可写 - 别用系统路径启动：避免在
C:Windows、/usr、/opt等系统目录下执行jupyter notebook - 改默认工作目录：运行
jupyter notebook --generate-config生成配置，打开~/.jupyter/jupyter_notebook_config.py，取消注释并修改为：
c.NotebookApp.notebook_dir = '/home/yourname/notebooks' # Linux/macOS # 或 c.NotebookApp.notebook_dir = 'C:\Users\yourname\Documents\Jupyter' # Windows
注意：c.NotebookApp.notebook_dir 路径必须已存在，且当前用户对该路径有读写权限；前面不能有空格，也不能带 # 注释符。
Linux/macOS 下 chmod 777 为什么经常失效
因为 chmod 777 只改当前目录权限，而 Jupyter 实际要写的是子目录（如 runtime/）或父目录（如 ~/.jupyter/）。更关键的是：某些环境（如 WSL2、容器、企业笔记本）启用了 noexec 或 nosuid 挂载选项，或受 SELinux/AppArmor 限制，此时 chmod 根本不起作用。
- 先确认挂载选项：
mount | grep $(df . | tail -1 | awk '{print $1}')，看有没有noexec或nosuid - 检查 SELinux：
sestatus，如果是 enforcing，临时设为 permissive：sudo setenforce 0（仅测试用） - 容器中运行？确保 volume 挂载时加了
:z（Podman）或:Z（Docker）标记，让 SELinux 正确打标 - 真正有效的是改归属：
chown -R $USER:$USER ~/.jupyter，而不是暴力 chmod
最容易被忽略的一点：很多用户修完 runtime 权限，却忘了检查 jupyter_cookie_secret 文件本身是否被设为只读——它也在 runtime/ 目录下，一旦被锁定，Jupyter 就无法更新会话密钥，照样报 Permission denied。
