post-receive写入/var/www/html被拒绝，权限相关技术问询

这问题我之前帮好几个朋友排查过，核心点在于Git钩子的执行环境和你手动通过SSH/WinSCP操作时的环境完全不同——哪怕你用同一个用户触发钩子，脚本运行时的有效权限、组继承可能根本不是你预期的状态。下面分几个常见原因和解决步骤：

1. 先确认脚本的执行用户/组到底是谁 #

别猜，直接在你的post-receive脚本最开头加几行调试代码：

#!/bin/bash
# 调试：记录当前用户、组信息
id >> /tmp/git_hook_debug.log
groups >> /tmp/git_hook_debug.log

然后触发一次钩子操作（比如push代码），查看/tmp/git_hook_debug.log里的内容。

• 如果发现脚本是git用户（或者其他非你的登录用户）执行的，那问题就明了了：这个用户不在Apache组里，自然没权限写/var/www/html。
• 解决方法：把执行脚本的用户加入Apache组：

  sudo usermod -aG apache git  # 这里的apache替换成你的实际组名
  

  注意：执行完后要让用户重新登录（或者重启Git服务），组权限才会生效。

2. 强制脚本以Apache组身份执行写入操作 #

有时候哪怕用户在Apache组里，脚本运行时的有效组并没有切换过去。这时候可以在脚本里用sg命令强制指定组来执行写入相关的命令。比如你的脚本里如果有git checkout -f这类写入操作，可以改成：

sg apache -c "git checkout -f"  # 同样，apache替换成你的实际组名

sg命令会让后面的命令以指定组的身份运行，确保拥有对应的写入权限。

3. 排查SELinux（针对CentOS/RHEL系服务器） #

这是最容易被忽略的点！哪怕文件权限完全正确，SELinux的安全上下文也可能阻止脚本写入。你可以先临时关闭SELinux测试：

sudo setenforce 0

然后再触发钩子，如果这次能成功写入，说明就是SELinux的问题。

• 解决方法：给/var/www/html设置正确的SELinux上下文，允许读写：

  sudo semanage fcontext -a -t httpd_sys_rw_content_t "/var/www/html(/.*)?"
  sudo restorecon -Rv /var/www/html
  

  这样就能让相关进程（包括Git钩子脚本）合法地写入该目录了。

4. 检查脚本本身的基础配置 #

最后确认两个小细节：

• 确保post-receive脚本有可执行权限：chmod +x hooks/post-receive
• 脚本开头的shebang要正确，比如#!/bin/bash，别用那种系统不认的shell路径。

按这个顺序排查，基本能解决90%以上的钩子写入权限问题。

内容的提问来源于stack exchange，提问作者R99