很多人看到 Jupyter Notebook 报出 PermissionError: [Errno 13] Permission denied，第一反应是重装环境，实际上大多数情况都和 Jupyter 本身无关。真正的问题通常出在它要写入的目录没有权限、文件被占用，或系统安全策略额外拦截了访问。
这篇文章按最常见的两类场景来拆解：一类是启动阶段卡在 runtime 目录，另一类是新建 Untitled.ipynb 时写不进去当前工作目录。你可以根据报错出现的时机，快速判断该查哪一个路径，再决定是修目录归属、清理残留文件，还是检查挂载和安全策略。
先判断：报错大多发生在哪几个位置
90% 的 PermissionError: [Errno 13] Permission denied 不是 Jupyter 坏了，而是它试图读写某个目录时，被 Windows 或 Linux 的权限机制拦住了。最常见的位置主要有三个：
~/.jupyter/runtime/（Linux/macOS）C:Users{用户名}AppDataRoamingjupyterruntime（Windows）- 当前启动 Jupyter 的工作目录，比如系统目录、挂载盘根目录或只读路径
如果是在启动 Jupyter 时报错，优先查 runtime；如果是点“New”新建笔记本时报错，优先查当前工作目录。
为什么 runtime 目录总报 Permission denied
Jupyter 启动后，会在 runtime 目录下生成 jpserver-*.json 和 jpserver-*-open.html 这类临时状态文件。只要这个目录的归属、写入权限或文件状态有问题，就可能直接触发 Permission denied。
常见原因有哪些
- Windows 上最常见的是
AppDataRoamingjupyterruntime目录存在，但当前用户没有“写入”权限，尤其是在重装系统或切换账户后 - Linux/macOS 上可能因为
chown或umask设置异常，导致~/.jupyter/runtime所属用户或组错乱 - 上次异常退出后遗留旧文件，新进程尝试覆盖旧的
.html文件时被拒绝 jupyter_cookie_secret文件被设成只读，也会让 Jupyter 无法更新会话密钥
更稳妥的修复步骤
处理这类问题时，关键不是直接 chmod 777，而是先停进程、清残留，再修归属和权限。
- 先关掉所有
jupyter notebook进程。Windows 可用任务管理器；Linux/macOS 可先执行：
ps aux | grep jupyter
kill -9- 进入报错路径，例如
C:Usersww57AppDataRoamingjupyterruntime，删除所有jpserver-*.json和jpserver-*-open.html文件 - Windows 中右键
runtime文件夹，依次进入“属性” → “安全” → “编辑”，给当前用户勾选“完全控制” - Linux/macOS 中执行：
chown -R $USER:$USER ~/.jupyter/runtime
chmod 700 ~/.jupyter/runtime如果修完目录权限后仍然报错，再单独检查 runtime/ 下的 jupyter_cookie_secret 是否被锁定或只读。
新建 Untitled.ipynb 提示 Permission denied 怎么办
如果你能打开 Jupyter 页面，但点击“New”创建 Untitled.ipynb 时失败，那通常和 runtime 没关系。真正报错的是 Jupyter 当前的工作目录，也就是默认保存笔记本的那个位置没有写入权限。
这些场景最常见
- 在
C:WindowsSystem32这样的系统目录下启动了 Jupyter - 当前目录是只读挂载的网络盘、加密 U 盘或挂载盘根目录
- 使用了权限受限的 Docker volume
怎么检查和修改工作目录
先确认你是从哪里启动的 Jupyter：
- Linux/macOS 运行
pwd - Windows 运行
cd
在执行 jupyter notebook 之前，先确保当前路径可写，并尽量避免在 C:Windows、/usr、/opt 这类系统目录下启动。
如果你希望固定一个默认工作目录，可以先生成配置文件：
jupyter notebook --generate-config然后打开 ~/.jupyter/jupyter_notebook_config.py，取消注释并修改为：
c.NotebookApp.notebook_dir = '/home/yourname/notebooks'# Linux/macOS
# 或
c.NotebookApp.notebook_dir = 'C:UsersyournameDocumentsJupyter'# Windows这里要注意三点：
c.NotebookApp.notebook_dir指向的路径必须已经存在- 当前用户必须对该路径有读写权限
- 配置行前面不能带多余空格，也不能带
#注释符
为什么 Linux/macOS 下 chmod 777 经常不管用
不少教程会建议直接 chmod 777，但这类做法经常治标不治本。原因有两个：一是你改到的可能只是当前目录，而 Jupyter 实际要写的是子目录或父目录；二是权限问题未必来自传统 Unix 权限位，可能来自挂载参数或强制安全策略。
它常见的失效点
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 挂载是否加了正确标记：
- Podman 使用
:z - Docker 使用
:Z
对这类场景来说，真正有效的通常仍是修正目录归属，例如：
chown -R $USER:$USER ~/.jupyter一套更省时间的排查顺序
如果你不想在多个目录之间来回试，可以按下面这个顺序处理：
- 先看报错发生在启动阶段，还是发生在新建笔记本时
- 启动时报错，就检查
runtime目录归属、残留文件和jupyter_cookie_secret - 新建时报错，就检查当前工作目录是否可写，是否误在系统路径中启动
- 如果普通权限都没问题，再继续查挂载选项、SELinux/AppArmor、容器 volume 标记
这样排查，通常能比直接重装 Jupyter 更快找到原因，也能避免用过度开放的权限设置把问题暂时“压下去”。
