Search code examples
podmanmounted-volumesrootless

How UID can be determined without running the container?

I am running the docker.io/library/mariadb:latest image using podman on Centos 8. I am mounting a volume on host for persistent storage for the database. I understand that the directory ownership on the host must be changed for the user inside the container to gain rw access. So we use podman's unshare command for that purpose. The user in mariadb is called mysql. If we enter

podman unshare chown mysql:mysql /path/to/host

This will error:

chown: invalid user: ‘mysql:mysql’

Which makes sense because mysql user does not exist on host. We must provide the UID for that purpose. This information is usually obtained from a running container and look up for mysql in /etc/passwd

 podman run docker.io/library/mariadb grep mysql /etc/passwd

And the UID/GID is 999:999 from the output below.

mysql:x:999:999::/home/mysql:/bin/sh

Now we can chown using the UID on the host

podman unshare chown 999:999 /path/to/host

And this works.

But, how can we obtain this information without running the container?

I have inspected the image and cannot find explicit UID:GID assigned. The reason for this question is to implement automated provisioning/setup of infrastructure without worrying about manual steps.

Solution

  • The easiest way to deal with this situation is to use a named volume, rather than a bind mount. For example, if we run...

    podman run -it --rm -v mariadb_data:/var/lib/mysql \
  -e MYSQL_ROOT_PASSWORD=secret  mariadb:latest

    ...then the container will start up without any errors. This form of the -v option causes podman to create a named volume, rather than using a specific existing host directory as we would with a bind mount.

    When mounting a named volume, the ownership of the volume is set to the UID under which the main container process is running, so it has the correct permissions by default.

    This gets you pretty much all the advantages of using a bind mount -- that is, the database data is maintained outside of the container filesystem and will persist even if the container is deleted -- without needing to muck about with permissions.