GitLab CI/CD流水线报错CI_SERVER_TLS_CA_FILE: Permission denied排查

你遇到的Permission denied错误是针对CI_SERVER_TLS_CA_FILE证书文件的访问权限问题，并非直接是gitlab-runner账户对repo_B的克隆权限问题，可从以下方向逐一排查：

1. 临时目录权限排查 #

• 检查GitLab Runner工作目录的权限配置：查看/home/gitlab-runner/builds/ixxkmE1bM/0/group_name/repo_A.tmp/的所有者和权限，确保gitlab-runner用户对该目录拥有读写权限。
  • 可在流水线中添加调试步骤，执行命令：

    ls -ld /home/gitlab-runner/builds/ixxkmE1bM/0/group_name/repo_A.tmp/
    id gitlab-runner
    

    通过输出结果确认目录权限、用户组是否匹配。
• 若使用Docker executor，需检查容器内工作目录的权限，确保容器内的runner用户（通常为gitlab-runner或root）可正常访问该临时目录。

2. CI_SERVER_TLS_CA_FILE变量配置校验 #

• 确认该变量是否被手动覆盖：若流水线中自定义了CI_SERVER_TLS_CA_FILE，可能指向了不存在或无权限的文件。可在流水线中添加命令输出变量值：

  echo $CI_SERVER_TLS_CA_FILE
  

  验证路径是否正确。
• 默认情况下GitLab会自动设置该变量指向正确的CA证书，若使用自签证书，需确保Runner配置文件中正确指定了tls-ca-file路径，且该文件对gitlab-runner用户可读。

3. repo_B的CI_JOB_TOKEN权限验证 #

虽然当前错误与克隆权限无关，但可验证配置是否生效：

• 在流水线中添加测试克隆命令：

  git clone https://gitlab-ci-token:$CI_JOB_TOKEN@gitlab.example.com/group_name/repo_B.git
  

  若克隆失败提示权限不足，才是repo_B的Token Access配置问题；若克隆成功，说明权限配置正常，错误点集中在证书文件访问环节。

4. GitLab Runner执行环境排查 #

• 若使用Shell executor，检查gitlab-runner用户的umask设置是否导致临时目录权限过严，或sudo权限是否异常。
• 若使用Docker executor，尝试切换为官方gitlab-runner镜像，排除自定义镜像的权限配置错误。

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