Trouble with volume permissions

I have a docker container with a mounted volume running on an Ubuntu 20 host. I’m having trouble figuring out permissions to write to the directory.

I don’t know what group to set the directory to. I set the directory to 775 on my host, but I get errors that I can’t write in from the docker container. When I change the directory to 777 , I see uploaded files are written as 82:82 , which I assume is the uid:guid from docker (this was for test purposes only).

I know I can set the user for the mounted directory (through docker compose), but I’m having trouble understanding if that means the user on the host or the container. I read somewhere I should create a host user with the same uid and then add that user to the group on the directory, but this feels like a really poor method; what if the id in the container already exists on the host? I could give the directory permissions to the 82 uid/guid, but same problem.

If my google-fu has failed me, can someone help me understand better permissions control on docker volumes, or if there are any patterns I should be learning/following on this?

When using bind-mounts, you need to allign the owner uid:gid of the host folder, with the uid:gid of the process inside the container. When a host path is mounted into a container path, a bind-mount is used. Another indicator that binds are used is that they are not listed by the command docker volume ls.

As the permission question usualy only makes sense for bind-mount “volumes” (which in reality are not volumes), the response will focus on bind-mounts:

The image description should indicate which uid:gid is used to start the main process of the container.

Some images are designed so that the entrypoint of the container is started as root, which starts the main process as a specific uid:gid.Some of those images provide environment variables to override the uid and gid using environment variables.

Other images are designed to start the entrypoint script with an unpriviliged user and run the main process with it. Those images have one or more USER instructiosn in the Dockerfile. For those type of images the uid:gid for the first declared USER instruction can be overriden using the --user ${uid}:${gid} argument.

And then there are images that start the entrypoint script with root privilges and run the main process with root priviliges.