docker volume 权限问题

[Bardon]

譬如：

docker run -d -v /path/web:/var/www nginx_name

就会出现 volume 权限问题，而 Dockerfile 中的

RUN chown -R nobody:nobody /path

则仅仅在构建的时候生效，或者说，在 -v 挂载 volume 后，就无效了，/path 的权限变为 host 的目录权限。

最恼人的是，各发行版 nobody 、 nginx 等的 UID GID 是不同的数字。就是说，我不能在 ENTRYPOINT 中通过 chown -R nobody:nobody 来解决。

网上搜索了一圈，发现一个 ENTRYPOINT 脚本，

http://stackoverflow.com/questions/23544282/what-is-the-best-way-to-manage-permissions-for-docker-shared-volumes

TARGET_GID=$(stat -c "%g" /volume/FOOBAR)

EXISTS=$(cat /etc/group | grep $TARGET_GID | wc -l)

# Create new group using target GID and add nobody user
if [ $EXISTS == "0" ]; then
    groupadd -g $TARGET_GID tempgroup
    usermod -a -G tempgroup nobody
else
    # GID exists, find group name and add
    GROUP=$(getent group $TARGET_GID | cut -d: -f1)
    usermod -a -G $GROUP nobody
fi

目的很简单，检查挂载 volume 的 GID ，如果不存在，则新建个相同 GID 的 tempgroup ，再加个用户到 tempgroup ；如果 GID 存在，则将 nobody 添加到该 GID 组中。

只不过容器构建的时候出错，提示 usermod groupadd 等命令找不到。况且，该脚本的逻辑本身存在问题，譬如如果 GID 99 能匹配到 GID 999 。

我现在是暴力的在 docker run 中直接运行 chown 命令

大家又是如何优雅的解决这个问题的？

[JavaFirstMaster]

我们跨时空遇到了相同的问题.苦恼

[Bardon]

@JavaFirstMaster 呃，我已经解决了，写一个 entrypoint.sh 脚本，在 ENTRYPOINT 中执行
设置 UID GID 变量，通过 stat -c %u /path/volume 和 stat -c %u /home/volume 来检查 volume 的 uid 与 gid，然后与 UID GID 变量来比对，进而进行 volume 权限的设置。

[Bardon]

@JavaFirstMaster
对了，还要检查容器自身的 passwd 与 group 有没有已经存在的 uid gid
所以，脚本有点繁琐

[sprite0616]

我日，发布镜像的这些人是怎么用的。