你遇到的这个卷权限问题，本质是容器内用户的UID（1000）和宿主机当前用户的UID不匹配，导致写文件时权限被拒绝。下面给你几个实用的解决办法：

方法1：直接指定宿主机用户的UID/GID运行容器 #

这是最简单直接的方案，Docker的--user参数支持直接传入宿主机的UID和GID，让容器内的进程以这个身份运行，完美匹配卷的权限。

你可以把运行命令改成这样：

docker run -it --rm \
  --user $(id -u):$(id -g) \
  naftulikay/circleci-lambda-rust:latest \
  -v $PWD:/home/circleci/project \
  .local/bin/build

这里$(id -u)和$(id -g)会自动获取当前宿主机用户的UID和GID，不管是谁执行这个命令，容器内的进程都会用和宿主机一致的身份，自然就能正常读写挂载的卷了。

方法2：启动容器时动态修改容器内用户的UID/GID #

如果你必须要使用容器内创建的${RUST_USER}（也就是circleci）用户，那可以在启动容器时先修改这个用户的UID/GID，让它和宿主机用户匹配，再执行构建命令。

需要注意的是修改用户UID需要root权限，所以我们可以先以root身份进入容器，修改完权限再切换回目标用户：

docker run -it --rm \
  -v $PWD:/home/circleci/project \
  --user root \
  naftulikay/circleci-lambda-rust:latest \
  sh -c "usermod -u $(id -u) circleci && groupmod -g $(id -g) circleci && chown -R circleci:circleci /home/circleci && su - circleci -c '.local/bin/build'"

这个命令的逻辑是：

• 以root身份启动容器
• 修改circleci用户的UID为宿主机当前用户的UID
• 修改circleci用户组的GID为宿主机当前用户的GID
• 重新设置/home/circleci目录的权限，确保用户能正常访问
• 切换回circleci用户执行构建命令

方法3：全局配置Docker用户命名空间重映射 #

如果你的环境需要长期解决这类UID冲突问题，可以配置Docker的用户命名空间，把容器内的UID范围映射到宿主机的一个安全范围内，避免和宿主机用户直接冲突。

操作步骤如下：

1. 编辑Docker的配置文件/etc/docker/daemon.json，添加以下内容：

{
  "userns-remap": "default"
}

2. 重启Docker服务使配置生效：

systemctl restart docker

这个配置会自动创建一个dockremap用户，容器内的UID会被映射到宿主机dockremap用户对应的UID范围，比如容器内的1000会映射到宿主机的100000+1000=101000，这样就不会和宿主机的普通用户UID冲突了。不过这是全局配置，会影响所有容器，适合作为长期解决方案。

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