Docker用户无法写入已挂载的文件夹 [英] Docker user cannot write to mounted folder

问题描述

我有以下设置：

  selenium-chrome:
    image: selenium/node-chrome-debug:3.141.59-neon
    container_name: chrome-e2e
    depends_on:
      - selenium-hub
    environment:
      - HUB_HOST=selenium-hub
      - HUB_PORT=4444
      - SHM-SIZE=2g
      - GRID_DEBUG=false
      - NODE_MAX_SESSION=1
      - NODE_MAX_INSTANCES=5
      - TZ=Europe/Brussels
    hostname: chrome-e2e
    networks:
      - build-network
    ports:
      - 5900:5900
    volumes:
      - ./target:/home/seluser/Downloads

硒测试在容器内运行，实际的测试代码不在容器内容器。使用Maven，我们可以处理容器的生命周期。
如您所见，我将Chrome下载文件夹（位于容器内）安装到应用程序的 target 文件夹中。一切都安装得很好，但是当Chrome尝试下载文件时，拒绝写入 / home / seluser / Downloads 的权限。
Docker将 / home / seluser / Downloads 的UID和GID设置为2100：2100。 Chrome本身是通过 seluser user运行的。

Selenium tests are run inside the container, the actual test code is outside of the container. Using Maven we handle the lifecycle of the containers. As you can see I mounted the Chrome download folder (inside the container) to the target-folder of my application. All is mounted well but when Chrome tries to download a file, permission is denied to write to /home/seluser/Downloads. The UID and GID of /home/seluser/Downloads is set to 2100:2100 by Docker. Chrome itself is run via the seluseruser.

我该怎么做才能赋予 seluser 有权写入2100拥有的文件夹吗？

What do I need to do to give seluser the permission to write to a folder owned by 2100?

预先感谢。
问候

Thanks in advance. Regards

推荐答案

Linux中的绑定挂载不会对uid或gid执行任何命名间隔，并且主机挂载正在运行封面下的装订架。因此，如果容器内的uid与主机上的uid不同，则会出现权限问题。我已经在其他容器中使用Fix-Perms脚本解决了这个问题。实现类似于以下Dockerfile：

Bind mounts in Linux do not perform any namespacing on the uid or gid, and host mounts are running a bind mount under the covers. So if the uid inside the container is different from the uid on the host, you'll get permission issues. I've worked around this in other containers with a fix-perms script. Implementing that looks like the following Dockerfile:

FROM selenium/node-chrome-debug:3.141.59-neon
COPY --from=sudobmitch/base:scratch /usr/bin/gosu /usr/bin/fix-perms /usr/bin/
COPY entrypoint.sh /entrypoint.sh
# use a chmod here if you cannot fix permissions outside of docker
RUN chmod 755 /entrypoint.sh 
USER root
ENTRYPOINT [ "/entrypoint.sh" ]

enterpoint.sh如下：

The entrypoint.sh looks like:

#!/bin/sh
if [ "$(id -u)" = "0" -a -d "/home/seluser/Downloads" ]; then
  fix-perms -r -u seluser /home/seluser/Downloads
  exec gosu seluser /opt/bin/entry_point.sh "$@"
else
  exec /opt/bin/entry_point.sh "$@"
fi

这里发生的是容器以root身份启动，并且fix-perms脚本调整容器内的 seluser 以匹配 / home / seluser / Downloads 目录。 exec gosu 然后以自己的用户身份运行容器进程，作为新的pid 1。

What's happening here is the container starts as root, and the fix-perms script adjust the seluser inside the container to match the uid of the /home/seluser/Downloads directory. The exec gosu then runs your container process as the seluser as the new pid 1.

您可以看到代码用于在以下位置实现此功能： https://github.com/sudo-bmitch/docker-base

You can see the code used to implement this at: https://github.com/sudo-bmitch/docker-base

我已经在一些演示文稿中讨论了此方法，包括： https://sudo-bmitch.github.io/presentations/dc2019/tips-and-tricks- of-the-captains.html＃fix-perms

I've discussed this method in several of my presentations, including: https://sudo-bmitch.github.io/presentations/dc2019/tips-and-tricks-of-the-captains.html#fix-perms

这篇关于Docker用户无法写入已挂载的文件夹的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！