上线后，页面能写、后台却读不到，常是权限错配：同目录中静态文件为 0644，临时文件为 0600，Worker 缓存却是 0660。目录、用户和发布方式任一不同，结果就会漂移；事后 chmod 还会把故障推迟到下次发布。
如果你正在选机器，或者想先把线路和配置跑通再谈长期方案，可以先看看这几家的线路说明和技术参数：hostwinds（全球云服务器），先看清带宽线路、流量策略和退款条款，再决定要不要迁。
一、权限在文件创建时定型
Linux 新建文件通常请求 0666，再由 umask 裁掉不允许的位；目录通常从 0777 计算。setgid 父目录让新对象继承目录组，新子目录也通常带 setgid，但它不改所有者，也不会把 0600 提升为 0644。
关键是谁以什么身份、在哪里创建。root、deploy 用户和 systemd 的 appsvc 账户可能得到不同 owner、group。应用若先在 /tmp 生成再 mv，权限在临时目录已定型；同文件系统内 rename 移动原 inode，不会因进入 setgid 目录重算。
跨文件系统时，mv 退化为复制再删除，可能改变权限且失去原子性。目标目录的 setgid 或默认 ACL 追不回创建偏差；发布后 chmod 还会制造可访问窗口。
二、用 setgid 与默认 ACL 预判结果
setgid 解决组归属，不等于权限模板。目录组应设为受控站点组，并确认发布用户属于该组或有特权，同时核对文件系统是否保留 setgid。普通用户若不属于该组，文件可能仍归 primary group；只看 s 位不够。
默认 ACL 可表达“新文件 0644、新目录 0755，仅 appsvc 可写日志”。设置 default ACL 后，新对象继承访问 ACL 与默认 ACL，umask 不再独自决定初始权限，mode 仍约束条目。验证须由真实发布账户创建样本，再用 stat、getfacl 检查，管理员代测不可靠。
稳定模型应分开职责：目录管组边界，默认 ACL 管权限模板，构建产物管 owner 和最终校验。产物先在同权限域、同文件系统的暂存目录生成，核对 mode、uid、gid、ACL 后，再用 rename 原子切换；跨文件系统则在目标端重建验收。
常见坑包括把 setgid 当自动 chmod、递归开放 0777、发布后补权限。审计应记录父目录 setgid、进程 uid/gid、默认 ACL 与产物最终 mode。ServLlama 可辅助查看服务身份和目录授权状态，但不能替代权限模型。
setgid、默认 ACL 与 umask 如何叠加
setgid 目录只决定新建对象的组：子目录通常继承目录组和 setgid 位，普通文件继承组，却不会继承 setgid 执行位。它也不赋予组成员资格；发布账号不在该组时，仍可能无法读取共享文件。应建立专用发布组，并按需让构建账号与 Web 服务账号加入，同时保证各级父目录具有 x 搜索权限。
默认 ACL可按主体精确授权，新建子目录还会继承默认 ACL；有效权限始终受 ACL mask 限制。对扩展 ACL 执行 chmod 可能重算 mask，造成权限突然失效。无默认 ACL 时，mode 与 umask 共同决定创建权限；有默认 ACL 时，内核按创建 mode 调整继承项，umask 不再以普通方式过滤它们。
常见坑是只修当前目录、不约束以后创建的发布目录，或直接用 777 兜底；此外，chown 可能清除 setgid。正确顺序是先确定属主和属组，再设置 mode、setgid 与 ACL，最后以实际服务账号验证。
站点授权与原子发布
生产站点可拆成 releases/、shared/ 和 current 符号链接。每个版本在独立目录构建，统一设置属主、组、setgid、ACL 与安全标签，Web 根目录指向 current/public。校验后执行 ln -s releases/v1 current.next，再以 mv -Tf current.next current 完成同目录原子切换，禁止直接覆盖正在服务的文件。
上传、缓存和会话应放在 release 之外的 shared，否则切换或回滚会造成数据分叉。还要保证 Web 用户能穿越各级父目录，密钥与日志不位于公开目录，并处理旧 worker、文件句柄、缓存失效、跨挂载点以及 SELinux 或 AppArmor 标签。
可执行检查清单：①运行 stat -c '%A %a %U:%G %n' /srv/site/releases/v1，核对权限、setgid 与属组；②运行 getfacl -p /srv/site/releases/v1，检查默认 ACL 和 mask；③用 namei -l /srv/site/current/public/index.php 验证路径每一级；④用 readlink -f /srv/site/current 确认实际版本；⑤运行 systemctl show site.service -p UMask 核对服务 umask；⑥将 nginx 替换为实际服务账号，执行 sudo -u nginx touch /srv/site/shared/.perm-test，检查组、mode、读取结果和安全标签后删除；⑦确认临时链接与 current 位于同一目录，并完整演练版本切换、回滚及 shared 写入。
权限继承只发生在对象创建时，并不等于持续授权。发布门禁应固化预期属主、组、mode、ACL 与标签，并以真实服务身份跑通“创建、读取、切换、回滚”；任何结果偏离基线都应停止发布，而不是临时放宽权限。
喜欢 
顶
难过
囧
围观
无聊
