为什么没有在Dockerfile中工作?

时间:2014-10-01 15:50:37

标签: docker chown

我的Dockerfile创建了一个目录,然后单击它,然后列出该目录。该目录仍由root拥有。那是为什么?

这是Dockerfile:

FROM ubuntu:precise
RUN useradd -d /home/testuser -m -s /bin/bash testuser
RUN mkdir -p /var/local/testrunner/logs
VOLUME ["/var/local/testrunner/logs"]
RUN grep testuser /etc/passwd
RUN grep root /etc/passwd
RUN chown -R testuser:testuser /var/local/testrunner/logs
RUN ls -ld /var/local/testrunner/logs 

以下是“docker build”的输出:

Sending build context to Docker daemon 10.24 kB
Sending build context to Docker daemon 
Step 0 : FROM ubuntu:precise
 ---> ab8e2728644c
Step 1 : RUN useradd -d /home/testuser -m -s /bin/bash testuser
 ---> Using cache
 ---> 640f12671c86
Step 2 : RUN mkdir -p /var/local/testrunner/logs
 ---> Using cache
 ---> bf7756fd5b1f
Step 3 : VOLUME ["/var/local/testrunner/logs"]
 ---> Using cache
 ---> 65c73ee76c20
Step 4 : RUN grep testuser /etc/passwd
 ---> Using cache
 ---> db72fff0b965
Step 5 : RUN grep root /etc/passwd
 ---> Running in ebff78df7a9a
root:x:0:0:root:/root:/bin/bash
 ---> ead0ff704a59
Removing intermediate container ebff78df7a9a
Step 6 : RUN chown -R testuser:testuser /var/local/testrunner/logs
 ---> Running in c925f67b2ab4
 ---> 253132be935e
Removing intermediate container c925f67b2ab4
Step 7 : RUN ls -ld /var/local/testrunner/logs
 ---> Running in 978bc66aa47e
drwxr-xr-x 2 root staff 4096 Oct  1 15:15 /var/local/testrunner/logs

Docker 1.2.0版,构建fa7b24f

主机运行Ubuntu 12.04,但使用3.13.0-36通用内核。

5 个答案:

答案 0 :(得分:97)

回答我自己的问题:它被宣布为一个卷。如果取出VOLUME指令,则chown生效。

更重要的是,如果在运行chown之后声明音量,则chown设置仍然有效。

答案 1 :(得分:7)

此博客http://container42.com/2014/11/03/docker-indepth-volumes/详细解释了此行为。

Dockerfile中的每条指令都会创建一个新容器。该指令对此容器进行了一些更改,并成为一个新层。对" / var / local / testrunner / logs"所做的更改在对实际容器文件系统进行VOLUME指令之前。但是,在VOLUME指令之后,目录" / var / local / testrunner / logs"是挂载的目录。 VOLUME指令后对此目录所做的更改将应用​​于已安装的目录,而不是实际的容器文件系统。

答案 2 :(得分:2)

对于没有卷的问题的任何人,我都发现了一个复杂的解决方案。

问题:

具有如下所示的简单Dockerfile:

FROM ubuntu:16.04
RUN useradd -m -d /home/new_user new_user
COPY test_file.txt /home/new_user
RUN chown -R new_user:new_user /home/new_user
CMD ls -RFlag /home

运行后:

echo "A file to test permissions." > test_file.txt
docker build -t chown-test -f Dockerfile .
docker run --rm -it chown-test

输出为:

/home:
total 12
drwxr-xr-x 1 root 4096 Jun 15 21:37 ./
drwxr-xr-x 1 root 4096 Jun 15 21:39 ../
drwxr-xr-x 1 root 4096 Jun 15 21:39 new_user/

/home/new_user:
total 24
drwxr-xr-x 1 root 4096 Jun 15 21:39 ./
drwxr-xr-x 1 root 4096 Jun 15 21:37 ../
-rw-r--r-- 1 root  220 Aug 31  2015 .bash_logout
-rw-r--r-- 1 root 3771 Aug 31  2015 .bashrc
-rw-r--r-- 1 root  655 Jul 12  2019 .profile
-rw-r--r-- 1 root   28 Jun 11 19:48 test_file.txt

如您所见,文件所有权(例如test_file.txt)仍与用户root关联。

解决方案:

我发现,如果在chown命令中使用数字UID,则可以更改所有权,但前提是UID不是1000。因此我在new_user的UID中添加了1,然后然后更改所有权。

FROM ubuntu:16.04
RUN useradd -m -d /home/new_user new_user
# change the uid of new_user to ensure it has whatever it was assigned plus 1 (e.g. if UID was 1000, now it'll be 1001)
RUN id -u new_user | awk '{print $1+1}' | xargs -I{} usermod -u {} new_user
COPY test_file.txt /home/new_user
RUN id -u new_user | xargs -I{} chown -R {}:{} /home/new_user
CMD ls -RFlag /home

运行后:

echo "A file to test permissions." > test_file.txt
docker build -t chown-test -f Dockerfile .
docker run --rm -it chown-test

输出为:

/home:
total 12
drwxr-xr-x 1 root 4096 Jun 15 21:37 ./
drwxr-xr-x 1 root 4096 Jun 15 21:37 ../
drwxr-xr-x 1 1001 4096 Jun 15 21:37 new_user/

/home/new_user:
total 24
drwxr-xr-x 1 1001 4096 Jun 15 21:37 ./
drwxr-xr-x 1 root 4096 Jun 15 21:37 ../
-rw-r--r-- 1 1001  220 Aug 31  2015 .bash_logout
-rw-r--r-- 1 1001 3771 Aug 31  2015 .bashrc
-rw-r--r-- 1 1001  655 Jul 12  2019 .profile
-rw-r--r-- 1 1001   28 Jun 11 19:48 test_file.txt

我不确定为什么首先要遇到这个问题。但是,由于其他人似乎都遇到了这个问题,所以我认为我应该发布解决方法。我的用例是创建一个服务于jupyter笔记本的docker容器。我创建了一个非root用户来为笔记本计算机服务。

答案 3 :(得分:0)

根据我的经验,chown在安装到根目录(VOLUME /test)时不起作用。使用非根目录位置(VOLUME /var/test)。

答案 4 :(得分:0)

对于 Alpine Linux用户,我不得不在我尝试拥有的工作区中进行chown -R root .。这必须在dockerfile的CMD中完成,因为我相信卷挂载在挂载时可能会覆盖文件