My setup
- Windows 11
- WSL2
- Docker Desktop v4.14.0 using WSL based engine
Known facts
- With file permission, the numeric user id counts
- OpenLitespeed Docker image uses
UID 999
Use case
We have a project where we use Openlitespeed Docker image. The docker-compose.yml defines the service like this:
litespeed:
image: litespeedtech/openlitespeed:${OLS_VERSION}-${PHP_VERSION}
env_file:
- ./.env
logging:
driver: none
volumes:
- ./lsws/conf:/usr/local/lsws/conf
- ./lsws/admin-conf:/usr/local/lsws/admin/conf
- ./bin/container:/usr/local/bin
- ./sites:/var/www/vhosts/
- ./acme:/root/.acme.sh/
- ./logs:/usr/local/lsws/logs/
- ./pub:/var/www/pub/
- ./install:/var/www/install/
- ./config:/var/www/config/
- ./.env:/var/www/.env
ports:
- 80:80
- 443:443
- 443:443/udp
- 7080:7080
restart: on-failure
environment:
TZ: ${TimeZone}
networks:
- default
When cloning the repo to a computer, the files in the working dir are owned by the current user, say, with UID 1000.
When starting the container, the bind mounted directories & files inherit the owner UID 1000 from the host computer.
The process in the container runs as user 999 and faces permission problems because 999 != 1000.
Probably the files should be owned by same uid the container is running as?
Well, we could chown the files to the user 999 to make it work in the container, but whenever we want to edit the bind mounted files on the host computer, we face permission errors, because files are owned by user 999, which probably doesn't even exist on the host computer.
Is the solution then to create the missing user with ID 999 on the host computer?
We could create it and add the actual user to the new user's group and allow write-permissions to group (chmod g+w). Now the files could be edited on the host computer by the actual user, and container works too.
But then a new file is needed. One creates it on the host computer and boom - it's owned by the current user, and again the container has problems.
How about leveraging the SGID bit to ensure file group stays consistent?
This could do. If all new files and directories in that directory inherit at least the group, the permissions should work both ways as the directories and files were previously made group-writable.
Ok, could work.
But how do we make this work across the development team?
We can't just assume everybody can create a matching user account with ID 999 on the host computer because that UID might very well be already reserved.
There must be a proper way to solve this, I've probably just overseen it totally.
