自托管GitHub Runner删除.git目录文件时遇Permission denied错误

核心原因 #

问题根源是GitHub Runner运行用户与工作目录/文件的所有者、权限不匹配，临时chmod 777只是粗暴开放权限，但后续生成的文件仍会因权限继承或用户归属问题再次出现拒绝。

解决方案 #

• 确认并修正Runner工作目录的所有者

  1. 先找到GitHub Runner的运行用户：

     # 查看Runner进程所属用户
     ps aux | grep runsvc
     # 或查看systemd服务配置（如果用systemd管理）
     cat /etc/systemd/system/github-runner.service | grep User
     

  2. 将Runner工作目录的所有者改为该用户（替换runner-user为实际用户）：

     sudo chown -R runner-user:runner-user /home/user/github-actions/
     

• 设置工作目录的权限继承规则
  给工作目录添加组权限继承，确保后续生成的文件自动匹配Runner用户的权限：

  sudo chmod -R 755 /home/user/github-actions/
  sudo chmod g+s /home/user/github-actions/1/_work/project/project/
  

  g+s会让目录下的新文件继承目录的组权限，避免权限断层。

• 调整Git仓库的权限配置
  如果问题集中在Git相关文件，修改Git的共享仓库配置，让克隆生成的文件支持组读写：

  # 全局配置（对所有仓库生效）
  git config --global core.sharedRepository group
  # 或针对当前问题仓库单独配置
  cd /home/user/github-actions/1/_work/project/project/
  git config core.sharedRepository group
  

• 禁止Workflow中使用sudo操作文件
  若Workflow里存在sudo执行的步骤，会导致文件所有者变为root，后续Runner用户无法操作。要么移除sudo，要么在sudo操作后手动修正权限：

  # 示例：执行sudo命令后立刻修正所有者
  sudo your-command-here && sudo chown -R runner-user:runner-user /home/user/github-actions/1/_work/project/project/
  

• 重启Runner服务生效
  修改完成后重启Runner服务，确保所有配置生效：

  sudo systemctl restart github-runner
  

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