GoCD代理prepare阶段执行git clean出现Permission denied错误如何解决

问题根因 #

你遇到的权限报错核心原因是dind模式下容器生成的文件所有者不匹配：

• GoCD代理默认以uid为1000的go用户运行流水线任务
• 当流水线中执行docker相关操作（比如容器内运行composer install、挂载本地目录执行命令等）时，容器默认以root用户（uid=0）运行，生成的文件/目录所有者为root
• 第二次运行流水线执行git clean时，go用户没有权限删除root创建的文件，就会触发权限报错

你修改宿主机godata目录权限只解决了初始状态的权限问题，对运行过程中动态生成的root权限文件无效。

解决方案 #

方案1：给go用户开放无密码sudo权限，流水线前置修复权限 #

这是适配性最强的方案，不影响现有流水线逻辑：

1. 修改自定义代理的Dockerfile，在USER root段添加sudo配置：

ARG GOCD_VERSION=v21.3.0

# GOCD image
FROM gocd/gocd-agent-docker-dind:${GOCD_VERSION}

USER root
# 新增：安装sudo并给go用户开放无密码权限
RUN apk add --update --no-cache sudo && \
    echo "go ALL=(ALL) NOPASSWD:ALL" >> /etc/sudoers
# Install compose
RUN apk add --update --no-cache \
    py-pip \
    python3-dev \
    libffi-dev \
    openssl-dev \
    gcc \
    libc-dev \
    rust \
    cargo \
    make \
    jq

ARG COMPOSE_VERSION=1.29.2

USER go
RUN pip install docker-compose==${COMPOSE_VERSION}

2. 重新构建自定义代理镜像后重启代理
3. 在所有流水线的第一个任务步骤添加权限修复命令：

sudo chown -R go:root ${GO_PIPELINE_WORKING_DIR}

该命令会在每次流水线执行前，把当前工作目录的所有文件权限改回go用户所有，后续git clean、代码编译等操作都不会有权限问题。

方案2：调整docker运行参数，指定执行用户匹配go的uid #

如果你的流水线中主动调用了docker run/docker-compose run命令挂载本地目录，可以直接指定运行用户和go用户uid一致，从根源避免生成root权限文件：

• 单独docker run命令添加参数：--user 1000:0
• docker-compose.yml中对应服务添加配置：

services:
  your-service:
    user: "1000:0"
    # 其余配置不变

该方案无需修改代理镜像，适合流水线docker操作可控的场景。

方案3：配置GoCD代理流水线工作目录为临时目录 #

如果不需要持久化流水线工作目录的内容，可以修改代理启动参数，指定流水线目录为容器内的临时目录，每次运行都会重新创建：
启动代理时添加环境变量-e GOCD_AGENT_WORKING_DIR=/tmp/godata/pipelines，该目录默认对go用户完全开放，不会有跨运行的权限残留问题。

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