2

I use build-arg to ensure my container runs with the same UID as my host user:

--build-arg UID=$(UID)

I am mounting a volume with:

-v $(PWD)/packages:/mnt/packages

Because I want my container to produce some output into that directory.

The directory belongs to the host user.

But, not matter what I try, the mountpoint in the container belongs to root. I can correct it with sudo in the running container:

function correct-mountpoint-permissions () {
  # Hack alert:
  #   When mounting a host volume, it belongs to root, no matter what I do in the host or in the Dockerfile
  #   Here we correct the situation by using sudo. It's not nice, but that's life
  #   Note: the same problem does NOT happen with *named* volumes, but that completely defeats the purpose of
  #   mounting the volume in the first place - which is to produce some output visible on the host.
  #   If I have to start copying from containers to host, mounting volumes offers no benefit
  sudo chown "$USER:$USER" "$PACKAGES"
}

But this is just ugly. I should not even need to have sudo installed in the first place, or sudo rights at all in my container.

The alternative is to either mount a named volume, which is difficult to access from the host, or to avoid mounting volumes in the container at all, and just docker cp from it when my container has produced the expected output.

Is there a simple way of mounting a host volume with the right ownership into a container (which means, not root, but my selected UID)

volingas
  • 1,023
  • 9
  • 21
  • The scope of a `build-arg` is limited to build time. Your run time environment may or may not have the UID set as you expect. – JR. Feb 08 '22 at 20:35
  • @JR.got it. These are private images, to be used on a single host. I use them to automate tasks which need execution in other OS (in this case, download python packages in a different OS than my host OS). UIDs are stable in this use case. – volingas Feb 09 '22 at 06:24
  • @volingas - Did you finally do something else other than this hack? I have a similar problem. – Saugat Mukherjee Sep 05 '22 at 14:58

1 Answers1

0

I understand you must be setting a user in your Dockerfile. Before the user is set , try changing the ownership of the user during the build of the image.

RUN chown -R myuser:myuser ${PACKAGES_DIR}
USER myuser
Rambler
  • 4,994
  • 2
  • 20
  • 27