![]() To your ~/.bashrc file (works in other shells, of course) append these two lines: export UID=$(id -u) There is margin for some kind of improvement… Solution 3: Store the variables in the config This will work as long as we stay in the current shell. Solution 2: Variable export $ export UID=$(id -u)īash: UID: readonly variable # ignore this, per above This is quick but not ideal: $ env UID=$ docker-compose run app idĪs you can see, user ID is set to my local user_id ( 1001), while group ID remained the same, because bash sets $GID to empty string (i.e., it’s not set at all). Here are six ways to do it (remember to open a new terminal after each one). How can we avoid those warning, and actually set the ownership to my user (which is 1001:1001 on my current machine) while using Docker? Defaulting to a blank string.Ĭreating docker-user-demo_app_run. If we open a terminal and run a command we can check we are doing stuff as root (I am going to omit the -rm flag for clarity, but, per the previous post, you may not want to keep the container around when playing with Docker): $ docker-compose run app id I’m told this works out of the box on Mac (I haven’t personally checked), while on Linux, if I run a command, I get a couple of interesting warnings, meaning that the command will be run as root.įor example, let’s print the user’s info. ![]() This is our initial docker-compose.yml: version: '3' There are multiple solutions to this problem: I’ll name a few. To avoid this we have to set user and group IDs somewhere. When I create a file using Docker (or, in my case, Docker Compose, the logic is the same in general), the file is created with root privileges, so I cannot directly edit them unless I chown them. In this case we talk about user and group. I have this problem: a client’s DevOps is a Mac user, meaning that their Docker works differently on my Linux machine¹.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |