香港服务器部署网站遇到目录访问拒绝，如何检查服务用户与目录权限？

目录访问拒绝可能让网站返回 403、图片或静态文件无法读取，也可能导致上传、缓存和日志写入失败。排查时先确认实际访问文件的服务进程身份，再逐级检查路径上的目录权限和文件权限；只有确认需要写入的目录，才授予对应服务用户写权限。不要用 chmod -R 777 作为快速修复，它会扩大整个目录树的访问范围，也会让回滚和追责更困难。

以下步骤适用于常见 Linux 网站服务器。执行前应确认网站根目录、Web 服务和应用服务名称，并确保有管理员权限。涉及修改的目录，应先记录现有权限与访问控制列表；操作期间尽量避免同时发布代码或调整服务配置，以免难以区分故障来源。

先界定影响范围

先判断是所有页面无法访问，还是只有某个目录、文件或写入功能异常。记录受影响的网址、对应的服务器绝对路径、错误时间及错误日志。若仅上传失败，问题更可能在上传目录的写权限；若静态文件返回 403，则应优先检查路径可遍历权限、文件读取权限和服务身份。

常见的权限判断关系如下：

目录的执行权限表示可以进入或遍历该目录，并不等同于运行程序。即使目标文件可读，只要路径中的某一级目录不允许服务用户进入，读取仍会失败。

确认真正访问文件的服务用户

不要仅凭发行版默认值判断服务身份。Web 服务、应用运行时和后台任务可能分别以不同用户运行；动态页面通常由应用进程读取代码，上传操作也可能由应用进程完成。

先识别服务名称和进程：

# Linux：查看常见服务及其进程；不存在的服务会显示错误，可忽略
systemctl --type=service --state=running | grep -E 'nginx|apache|httpd|php|fpm'
ps -eo user,group,pid,comm,args | grep -E '[n]ginx|[a]pache|[h]ttpd|[p]hp-fpm'

在 systemd 管理的服务上，可查看服务的启动配置和身份相关设置：

# 将 SERVICE 替换为实际服务单元名称，例如 nginx 或实际安装的应用服务单元
systemctl show SERVICE -p User -p Group -p MainPID
systemctl cat SERVICE

systemctl show 中的 User、Group 可能为空，这不一定代表服务使用当前登录用户；服务可能在启动后由主进程创建不同身份的工作进程。应结合 ps 输出和服务配置判断。某些服务的主进程以管理员身份启动、工作进程以普通用户身份运行，真正读取请求文件的通常是工作进程。

如果网站使用独立的应用运行时，也要检查对应进程池或服务配置中的用户、组设置。修改配置之前，先确认该用户是否为多个站点共用；共用身份下的权限调整可能影响其他站点。

逐级检查目录和文件权限

将示例路径替换为故障文件的实际绝对路径。namei 可以显示路径各级目录的所有者和权限；若系统没有该命令，可用 stat 逐级检查，或先安装系统仓库提供的对应工具。

# Linux：只读检查，不会更改权限
namei -l /srv/site/public/index.html
stat -c '%A %a %U:%G %n' /srv /srv/site /srv/site/public /srv/site/public/index.html

检查时关注两类条件：

• 从文件所在目录一直到根路径，服务用户都必须有目录遍历权限。目录所有者、所属组和其他用户的权限位中，至少有一组应适用于服务身份。

• 要读取文件，服务用户还需要对文件具有读取权限；需要列出目录内容时，还需要目录读取权限。写入文件通常还要求目标目录允许创建或替换文件，不能只检查已有文件本身。

再用服务进程的用户身份做一次访问测试。将 SERVICE_USER 替换为已确认的服务用户：

# Linux：以指定服务用户检查读取权限；路径应为实际网站文件
sudo -u SERVICE_USER test -r /srv/site/public/index.html
echo $?

# 检查目标目录能否遍历，以及是否可写
sudo -u SERVICE_USER test -x /srv/site/public
echo $?
sudo -u SERVICE_USER test -w /srv/site/uploads
echo $?

返回码 0 表示对应测试成立，非 0 表示不成立。测试结果可以快速定位权限缺口，但不能完全代替实际请求验证：访问控制列表、强制访问控制策略和服务自身的限制也可能影响结果。

如系统启用了访问控制列表，可查看目录及文件的 ACL：

getfacl -p /srv/site /srv/site/public /srv/site/public/index.html

如果标准权限位看起来允许访问，但服务仍报拒绝，应继续检查 ACL 中是否存在限制、默认 ACL 是否影响新建文件，以及安全策略是否拒绝了访问。不要为了验证方便直接清空 ACL；先保存当前输出。

先检查服务配置与安全策略

确认服务读取的站点根目录是否与排查的路径一致。配置指向旧目录、符号链接指向不可访问位置，或应用把上传目录设在另一处，都可能造成“权限似乎正确但请求仍失败”。符号链接本身及其目标路径上的每级目录也必须允许服务用户遍历。

从服务错误日志中查找拒绝访问的具体路径和操作类型。日志可能区分读取失败、无法进入目录或无法创建文件。不要公开粘贴包含密钥、用户数据或完整请求参数的日志。

如果权限位和用户组都正确，检查系统是否启用了 SELinux 等强制访问控制机制：

# 仅在系统提供相应命令时执行
getenforce
ls -Zd /srv/site /srv/site/public /srv/site/uploads

若策略处于启用状态，应结合系统审计日志和该目录原本应有的安全上下文判断。不要直接关闭安全策略，也不要对整棵网站目录盲目重设上下文；错误的宽泛调整可能影响其他服务或掩盖真正原因。根据部署方式修正具体目录的策略，并在修正后重新验证。

按最小范围修复并保留回滚依据

确定实际需要后，再选择修复方式。若服务用户已经属于网站所属组，通常优先修正目标目录的组权限；若服务用户不应加入该组，可考虑对确需访问的目录设置 ACL。静态代码目录一般只需服务进程读取，上传、缓存等写入目录则单独授权。

修改前保存权限和 ACL，以便恢复。以下命令适用于 Linux；保存文件应放在网站目录之外，并由管理员妥善保管：

# 修改前记录指定目录及其子项的权限和 ACL
sudo getfacl -R -p /srv/site > /root/site-permissions.before.acl

如果问题明确是某个目录缺少所属组的写权限，且该组确实是服务进程可用的组，可只调整该目录，不递归修改网站代码：

# 示例：仅调整上传目录的所属组和组写权限
# 执行前确认 SERVICE_GROUP 正确，且此目录确实需要由服务写入
sudo chgrp SERVICE_GROUP /srv/site/uploads
sudo chmod 2770 /srv/site/uploads

2770 使目录所有者和所属组可读写、进入，其他用户无权限；前置的特殊位让新建内容继承该目录的组。该设置适合由受控用户组共同管理上传目录的场景，不适用于所有部署。若服务用户不属于该组，设置后仍可能无法写入。必要时先核实组成员关系：

id SERVICE_USER

也可仅为服务用户添加目录 ACL，避免扩大其他用户的权限：

# 示例：只给指定服务用户访问上传目录的权限
sudo setfacl -m u:SERVICE_USER:rwx /srv/site/uploads
sudo setfacl -d -m u:SERVICE_USER:rwx /srv/site/uploads

第一条作用于现有目录，第二条设置该目录下新建内容的默认 ACL。是否需要默认 ACL，取决于后续文件和子目录是否也要由服务访问；不需要时不要添加。执行后用 getfacl 检查结果，并通过服务用户测试读、写和遍历能力。

避免对整个网站使用递归写权限。递归命令可能改坏代码文件、凭据文件和其他站点的权限，也可能使新发布的文件继承不合适的权限。若确需批量变更，应先限定准确路径、保存原始状态，并确认不会跨越符号链接或影响共用目录。

验证恢复，并在异常时回滚

权限调整后，先使用服务身份测试实际需要的操作，再发起真实请求。读取场景应确认页面或静态文件正常返回；上传场景应上传一个可识别的测试文件，检查文件是否生成、所有者和权限是否符合预期，随后按站点正常流程清理测试文件。不要只凭命令没有报错就判断故障已恢复。

如果服务配置也有变更，先执行该服务支持的配置检查，再按需重载或重启；具体命令取决于服务类型和发行版，先核实服务单元名称。仅调整文件权限通常不需要重启服务。

若修复后影响其他站点、文件无法读取，或权限范围超出预期，应停止继续扩大授权，并根据变更记录恢复。可用保存的 ACL 文件恢复原 ACL：

# 回滚前确认路径仍为原目录，避免把旧权限应用到已替换的网站树
sudo setfacl --restore=/root/site-permissions.before.acl

该操作会恢复记录中的访问控制信息；若期间还调整了文件所有者、所属组或安全上下文，这些变更需依据操作前记录分别恢复。没有可靠记录时不要猜测原权限，更不要通过全目录放宽权限来掩盖回滚不完整。

恢复优先级应是先让必要的页面和业务功能恢复，再确认上传、缓存等写入功能，最后复核权限是否仍遵循最小授权。故障处理完成后，至少检查服务实际用户、路径各级权限、写入目录清单、ACL 或安全上下文、测试请求结果，以及备份文件能否用于回滚。定期演练“读取失败”和“写入失败”的定位过程，可减少下一次变更时把权限问题误判为应用故障。