Linux运行Python脚本报Permission denied怎么解决

一、两种运行方式与权限校验机制

在深入排查之前，有必要先弄清执行 Python 脚本的两种常见形式。许多初学者在输入不同命令时常产生疑惑：为什么同一个脚本文件，通过某种命令能正常跑起来，换一种写法就会立刻报错？这是由 Linux 操作系统底层的系统调用规则决定的。

1. 直接执行形式：./script.py

当在终端输入 ./script.py 时，用户实际上是请求 Shell 将该脚本作为一个可执行二进制或脚本程序来启动。此时 Shell 会调用 Linux 内核的 execve 系统调用。

内核在执行文件前，首先检查当前用户对该文件是否拥有可执行权限（x 权限）。如果文件属性中没有 x 位，内核会立刻拒绝请求并向终端返回 bash: ./script.py: Permission denied，此时甚至还没有加载 Python 解释器。如果具备 x 权限，内核才会读取脚本第一行的 Shebang（如 #!/usr/bin/env python3），找到对应的 Python 二进制路径来解析脚本。

2. 显式解释器形式：python3 script.py

使用 python3 script.py 时，操作系统启动的程序其实是 Python 解释器二进制文件（例如 /usr/bin/python3），该文件本身在安装时已具备系统级的可执行权限。

对于 Python 解释器而言，script.py 只是一个传给它的文本参数。解释器通过标准的文件只读接口（open(..., 'r')）读取源码。因此，只要当前用户对脚本拥有读权限（r 权限），即便脚本完全没有执行权限（x 位），程序依然能够顺畅执行。

二、报错原因排查决策与定位流程

当遇到 Permission denied 时，不要盲目修改系统权限或直接执行危险的高权限命令。首先根据终端给出的报错提示形式，判断问题是发生在 Shell 启动阶段，还是发生在 Python 代码运行阶段。

通过上面的决策图可以清晰看出，排查的第一步是确认报错的主体：

• Shell 抛出的报错：终端第一行提示为 bash: ./script.py: Permission denied 或 zsh: permission denied: ./script.py。这证明问题发生在进程启动前，排查重点是文件权限位、挂载点属性以及 Shebang 声明。
• Python 抛出的异常：终端打印出了 Python 回溯信息（Traceback），末尾为 PermissionError: [Errno 13] Permission denied: '...'。这说明脚本已经成功启动，但执行到某行代码时，试图访问未授权的文件、目录或系统端口。

三、情况一：脚本直接运行时报权限不足的解决步骤

这是最普遍的一种情况。新建 Python 脚本时，Linux 默认的 umask 通常会创建出权限为 -rw-r--r--（644）的文件，默认不包含可执行位。要让脚本可以直接运行，请按以下步骤操作。

第一步：查看当前文件权限与所有者

在终端切换到脚本所在目录，执行长列表查看命令：

$ ls -l script.py
# 示例输出：
-rw-r--r-- 1 dev dev 482 Oct 30 21:00 script.py

在输出信息中，首段共 10 个字符。第 1 位 - 表示普通文件；接下来的第 2 至 4 位代表文件所有者（User）的权限。这里的 rw- 表示当前用户只有读取与写入权限，缺少代表执行的 x。

第二步：为脚本添加执行权限

使用 chmod（Change Mode）命令为文件补充执行权限：

# 推荐方式：为所有者赋予执行权限
$ chmod u+x script.py

# 或者标准脚本授权（所有者读写执行，组与其他用户读执行）：
$ chmod 755 script.py

# 复查授权结果：
$ ls -l script.py
-rwxr-xr-x 1 dev dev 482 Oct 30 21:00 script.py

此时可以看到，所有者权限段已经变为 rwx，表示脚本已经具备了作为可独立程序运行的基础条件。

第三步：核验脚本首行 Shebang 声明

当脚本被直接执行时，Linux 内核通过第一行的 Shebang 来识别应该调用哪个解释器。如果第一行缺失或指向错误的解释器路径，系统同样无法正确派生进程。

#!/usr/bin/env python3
# -*- coding: utf-8 -*-

import sys

def main():
    print(f"Python 脚本执行成功！解释器路径: {sys.executable}")

if __name__ == "__main__":
    main()

第四步：验证执行结果

确保前两步完成后，通过相对路径或绝对路径执行脚本：

$ ./script.py
# 示例输出：
Python 脚本执行成功！解释器路径: /usr/bin/python3

# 检查命令退出码（0 表示成功）：
$ echo $?
0

四、情况二：Python 运行时读写文件报 PermissionError

若脚本通过 python3 script.py 启动后，终端报出了 Python 的内置异常 PermissionError: [Errno 13] Permission denied，则说明执行权问题已经解决，症结在于 Python 进程对某些外部数据资源缺乏读写权限。

$ python3 script.py
Traceback (most recent call last):
  File "script.py", line 12, in <module>
    with open("/var/log/my_app.log", "w") as f:
PermissionError: [Errno 13] Permission denied: '/var/log/my_app.log'

解决这类运行时文件权限问题，应按以下逻辑逐步处理：

1. 检查父级目录的写入权限：新建文件时，用户不仅需要目标文件的权限，更必须对目标文件所在的上级目录拥有写入（w）和检索（x）权限。例如，普通非 root 用户默认无法在 /var/log 或系统根目录下直接新建文件。
2. 调整应用工作路径：生产实践中，应将日志、缓存与临时输出文件存放在当前用户有完整权限的目录中（例如用户家目录下的 ~/logs/ 或应用独立目录），而不是直接写入系统全局目录。
3. 修正已有文件的所属者与组：如果文件之前曾被 root 用户运行过，可能会留下属主为 root 的残留文件，导致普通用户后续无法读写。可使用 chown 修复属主：
   BASH 终端操作修正文件归属

   # 将文件属主变更为当前登录用户（示例用户名为 dev）：
   $ sudo chown dev:dev /path/to/my_app.log

五、情况三：监听受限低位网络端口或特殊系统资源

当使用 Python 开发简易 HTTP 服务、Socket 监听服务或 DNS 工具时，如果绑定的端口号小于 1024（如 80、443、53、22 等系统特权端口），直接以普通用户运行也会引发 PermissionError: [Errno 13] Permission denied。

# 方案 1（最佳工程实践）：在开发/测试时直接使用大于 1024 的非特权端口
import http.server
import socketserver

PORT = 8080  # 改用 8080 或 8000，无需任何系统特权即可绑定
Handler = http.server.SimpleHTTPRequestHandler

with socketserver.TCPServer(("", PORT), Handler) as httpd:
    print(f"服务正在端口 {PORT} 运行...")
    httpd.serve_forever()

在生产环境中，如果必须对外暴露 80 或 443 端口，业界标准做法通常是使用 Nginx / Caddy 等反向代理软件在前台监听 80 端口，再将流量转发给运行在 8000+ 端口的普通权限 Python 进程；或者利用 Linux Capabilities 机制赋予 Python 单项绑定特权（setcap 'cap_net_bind_service=+ep' $(which python3)），而尽量避免以 root 身份常驻运行整个 Python 解释器。

六、权限模型知识总结与安全最佳实践

解决权限问题的同时，必须牢固树立 Linux 系统的安全边界意识。很多开发者为了图一时省事，遇到权限报错就盲目执行 chmod 777 或全盘加上 sudo，这往往会埋下严重的安全隐患和后续维护难题。

安全准则清单：