开发者工具 · Chmod 计算器

修复 nginx 403 禁止：重要的文件和目录权限

2026年7月20日 · 为什么它很重要

chmod UNIX 访问控制

403 通常是文件系统问题，而不是配置问题。这篇文章展示了如何检查 nginx 作为哪个用户运行以及它在路径中的每个目录上需要哪些位。

403 在本地工作的静态站点上 - 文件来自 /home/deploy 并且 nginx 对每个 URL 表示禁止

nginx 403 可能涉及模式位，但此路由无法识别其原因。该计算器没有 nginx 集成、日志、配置解析器、进程查找或路径遍历器。它回答了更狭隘的问题：目录类是否已执行以及常规文件类是否已读取，从而帮助解释在其他地方收集的证据。

从每个路径组件上观察到的精确模式开始，而不是假设默认值。进入每种模式并选择其目标类型。符号文本、复选框和散文公开类权限并确认转换，但无法显示 nginx 尝试访问、它使用的身份或文件系统权限是否产生响应。

计算器无法发现 nginx 工作人员身份。它对所有者、组和其他类进行建模，但不对用户名、进程或成员资格进行建模。因此，像 rwxr-xr-x 这样的模式没有说明工人是否拥有该对象、属于其组还是属于其他组。外部检查必须确定该分类。

身份发现必须先于相关位的声明。一旦证据确定了适用的类别，矩阵就会显示读为 4、写为 2 并执行为 1。在此之前，编辑组或其他都是猜测。该路由未读取任何进程状态；它转换提供的模式而不是推断服务器体系结构。

将每个目录组件作为单独提供的模式进行检查。对于目录，执行允许条目和基于名称的访问，读取允许列出，写入允许创建、重命名和删除条目。特定于目标的解释可帮助审阅者确定外部建立的类是否已在特定组件上执行，而无需声明检查路径本身。

浏览器不会从根目录走到 Web 根目录。它无法定位阻塞组件、确认其存在或检查 ACL。分别提供每个观察到的目录模式，然后将最终对象作为常规文件进行检查，其中读取涉及内容而不是列表。这会解释收集到的证据，而不是取代文件系统检查。

对于静态文件，644 呈现 rw-r--r--。所有者接收读和写，而组和其他接收读；没有人收到执行。此转换表明文件读取和执行是单独的位。该页面没有决定特定服务器是否需要执行的依据，因为不存在服务器策略。

保持文件和目录的解释不同。目录执行意味着条目和基于名称的可达性，而常规文件执行意味着运行程序。因此，同一个复选框具有针对特定目标的散文。将 644 与 755 进行比较可以澄清一些问题，但无法在没有配置、身份、ACL 和策略上下文的情况下诊断 403 或规定通用模式。

支持的示例在其他地方收集路径证据后开始。假设目录组件为 755，最终文件为 644。计算器将目录呈现为 rwxr-xr-x，将组和其他执行解释为入口和可达性。它将文件呈现为 rw-r--r--，将组和其他读取解释为内容访问。

如果一个组件是 750，它的另一个三元组是 ---，而组仍然是 r-x。这种差异可能很重要，但并不能证明 nginx 使用其他的。该路由不能运行 namei 或 ls，因此外部证据必须提供路径和模式。然后，它会同步每个表示，以减少审核期间的转录错误。

所有权决策保留在模式转换之外。该面板不读取任何所有者或组，也不提供 chown 或 chgrp 操作。它无法在部署、服务或共享组所有权之间进行选择，也无法评估移动内容。这些决策需要来自来源的系统和工作量证据；没有生成模式可以替代该上下文。

一旦在其他地方解决了所有权问题，请比较模式如何划分访问权限。模式 750 授予完全所有者权限、组读取和执行权限，而不授予其他权限； 755 添加其他读取和执行。这仍然以了解工人阶级为条件。惰性命令预览既不更改所有权也不确认服务器访问权限。

此处不诊断配置、索引选择、强制访问控制和上游行为。没有源加载 nginx 配置、检查 URI 或索引、读取日志、联系上游或观察 SELinux 或 AppArmor。因此，正确转换提供的模式无法确定 nginx 返回 403 的原因；服务器证据必须回答这个问题。

当模式显得可疑时保留这种区别。该面板可能会显示目录类缺少执行或文件类缺少读取，但相关性取决于身份和路径证据。许可位也不能排除其他原因。准确说明该模式允许的内容，然后返回到特定于服务器的诊断。

路径访问可能取决于每个组件，但计算器一次只能看到一个提供的值。它的优势在于准确的解码：八进制、符号文本和复选框保持同步，而目录散文则区分列出、修改和输入。它简化了审查，而无需假装发现组件或尝试访问的进程。

建立服务器身份并收集该路由之外的路径模式。将每个目录解码为目录，将最终对象解码为常规文件，重点关注外部验证的类。分别调查配置、ACL 和强制策略。计算器验证算术，但无法识别 403 的原因或验证修复。