-
-
Notifications
You must be signed in to change notification settings - Fork 168
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
On Linux Containers Expect UID/GID of 1000 Otherwise Cause Permissions Trouble #155
Comments
Stumbled across the following used by code-server images and it looks potentially very useful here: https://github.com/boxboat/fixuid |
Hey, I'm encountering exactly this issue as my host user is UID/GID 1002. I'm working around this every time I spin up the containers by bashing into the PHP container and running:
Once I exit and bash back in, the commands work with the right permissions But because PHP-FPM itself is already running, that's still running as uid 1000 so I still need to fight with permissions. Refreshing static content on Magento requires:
I have two questions:
|
Eventually, yes. :) It's going to take some critical thinking through image changes, and possibly some other things to ensure it doesn't only solve the issue on Linux, but maintains existing functionality on Mac OS environments. There is no ETA however, as I haven't found the time to dedicate to resolving it yet. I may take a renewed look at it if more folks begin to run into this being the only big show stopper issue for them. |
Is this still relevant? If so, what is blocking it? Is there anything you can do to help move it forward? This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. |
This problem is even more severe if you don't have o+rX permissions on files as nginx seems to run with uid/gid 101. Would you accept a pull request with an update to the nginx container to run with the same pid/gid as php-nginx (1000)? Edit: A simple workaround seems to be to create a new user with uid/gid 1000 and add nginx to this group: docker exec -ti envname_nginx_1 bash
# ...
useradd app
usermod nginx -aG app
kill 1
# ... this will result in the container dying
warden env up Edit 2: Perhaps a general (and quite simple) workaround is to add a variable to env allowing a user/group id to be specified which php and nginx container users are added to. |
Considered using warden on Ubuntu but apparently this is not working. Almost all of the docker environments that also work on linux have a configurable uid/gid in a .env file, and using these to set www-data to configured uid/gid.
|
I also have the same issue when I make the environment down or up. So what I'll do spin up the environment with sudo usermod -u 1001 www-data
sudo groupmod -g 1001 www-data After that i'll finally run the and then I'll only use @davidalger is there any quick fix you might have that we can implement like with |
It's still an issue on Ubuntu 22.04 |
is there any improvement |
On most Linux systems (and inside Docker Desktop VM on macOS) the default UID/GID of 1000 is used for the first non-system account created. Due to this, the fpm containers Warden uses tie the
www-data
user to UID 1000 and GID 1000 so that permissions will work. This is inflexible and will not work, for example, where the user account on the Linux environment used by a developer uses a non-1000 UID.@aepod passed along the following script as a possible reference point on how to achieve solving this inflexibility in the entrypoint scripts: https://github.com/sudo-bmitch/run-as-user/blob/master/entrypoint.sh
In order to make the containers used more flexible, the stuff in the Dockerfile setting up the www-data user will need to be updated and/or moved to the entrypoint: https://github.com/davidalger/warden/blob/develop/images/php-fpm/Dockerfile#L35-L45 and two places in existing entrypoint which will need to be made flexible: https://github.com/davidalger/warden/blob/develop/images/php-fpm/context/docker-entrypoint
The text was updated successfully, but these errors were encountered: