I used docker-compose up with the following docker-compose.yml
version: '3.5'
services:
mysql-server:
image: mysql:5.7
environment:
- MYSQL_ROOT_PASSWORD=root_pwd
volumes:
- ./var/lib/mysql:/var/lib/mysql:rw
The directory ./var/lib/mysql does not exist initially.
After running docker-compose up ..
ls -al ./var/lib/mysql command shows all the files with user:group 999:999.
I cannot find user or group called 999 in my system.
Why docker-compose chooses to create files with a non-existing uid:gid ?
In my case, I cannot commit the specific directory unless I change ownership. But even when I do, on a next run, docker-compose up updates the ownership again to 999:999.
What is the solution to the above problem? e.g. Is there a way to instruct docker-compose to map files in host machine with a specific uid:gid pair?
Host: ubuntu-18.04
docker-compose: 1.22.0
Docker creates and populates the directory with the user that mysql image uses. That user, of course, has an uid within the container. That uid happens to be 999.
The user with that uid exists in the container but does not exist in your host.
On the container the folder looks like this:
root@f86ffddac96c:/var/lib# ls -l
total 32
...
drwxr-xr-x 5 mysql mysql 4096 Mar 19 13:06 mysql
...
and on the host it ends up looking like this.
root@machine:/home/username/mysql/var/lib# ls -l
total 4
drwxr-xr-x 5 999 docker 4096 Mar 19 15:06 mysql
This just simply means that the user mysql has uid of 999. And as you are creating a bind volume from container to host, all files within that volume must have same permissions for same uids. On my test machine docker has guid of 999, which is why it is displayed as such on the host side.
As for "fixing" this you can either use a (host-level) known uid in the dockerfile instead of the default one, or you can just ignore it, as it is working exactly as intended, unless there's a specific reason why you want it to display a certain name for a certain uid in your host system.