-
Notifications
You must be signed in to change notification settings - Fork 5.2k
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
Support --user option in "docker-compose up" #1532
Comments
I'm not sure I understand, I guess we'd need to support environment variable resolution in the |
Hi. Yeah, The point is to allow specifying the user without touching yml. |
It never occurred to me that people might want to do this. Could you elaborate on the use case? |
Never mind, I scrolled up. Am I right in thinking you're on Linux? When using boot2docker it creates files with sensible permissions. I wonder if there's a way to configure the Docker daemon to do this for every volume it mounts. |
Yes, on Linux. I'm using compose to run tests on CI by mounting host volume (yeah, I know). Without this option, some files get created with "wrong" ownership, i. e. root:root |
I know I could use a data only container and inspect/copy files from it, but a host volume is much more convenient and requires less scripting. |
@mrzechonek I don't think that modifying a container because of its environment is a good practice. |
@josephpage yeah, it might be. $UID expansion would do the trick though. Pretty much the only thing I need is proper permissions on host volumes. I don't know of any other way to achieve that, besides running container process as $UID... I would actually prefer this feature to be present in the Damon itself, like @aanand said. Or maybe an option to mount a volume in such a mode (a storage driver maybe?). |
@mrzechonek, have you found a workaround? |
Not really, no. Right now we're doing |
#1377 is in master and will be in the 1.5.0 release, so you'll be able to do I'm going to close this issue since the feature itself is implemented as part of #1377 |
This is actually not the first time I've heard of the need for this (although in this case I guess it's just temporary). I have a proposed fix for it in #2042 |
Thank you, #1377 fixes this nicely. |
@mrzechonek Could you clarify how this solved your problem? I have the exact same use case: "I'd like the dockerized app to generate files owned by me, not the root" I tried adding
The file |
I've used |
Having the exact same problem as @michaelmior. When using $USER instead I get What could cause $UID not being available during docker-compose execution? |
Hi, same problem here. workaround: |
Would be nice if docker-compose just made |
If |
So compose simply as a running application has no way of inferring the user it's running as? |
Sure, it could read the |
I'm more thinking that if UID isn't declared, then the executable could look at the uid of who ran it and make it available as such. Again, thinking about boilerplate and easy to overlook steps. Most people want a setup where the only step is |
UID was not availible directly see docker/compose#1532
Is there a nice resource that spells out any other similar gotchas between Mac and Linux hosts? |
Also, forcing the user isn't really what we want on Linux, we want the behavior that Mac has, where even when you run as root in the container, new files on host volumes have useful permissions :( |
+1 for docker-compose up --user or executing user .... |
Is there any solutions or news on this problem? |
Nope, and I opened this feature against the docker engine quite some while ago: moby/moby#22415 I think this is a much higher impact issue than it's being recognized for currently. Being able to alter what user the container touches the filesystem as without having to make the container itself aware of the permissions systems would open up quite a few doors. If this is something you're interested in, I suggest sharing and upvoting the ticket I linked. |
this works for me: |
@jovanialferez FYI if you hardcode it like that, you'll run into trouble if other people are involved in the project that don't have their UID and GID set to 1000. I think OSX starts numbering regular users at 500, and any Linux install with multiple users would end up with a UID greater than 1000. |
@jovanialferez that will only work on Linux. |
noted. thanks @nfm @luispabon |
I recently moved from Mac to Linux and just got hit by this, don't really understand how this is not solved yet |
Mentioning this issue again so that newcomers see it: moby/moby#22415 We really need the ability to externally map docker processes to a specific user. Emphasis on externally. Not choose the UID/GID of the process in the container. But map the container process to a local UID/GID from the outside. |
Yes, indeed. Assigning the uid/gid of the current user into the container only works in Linux. Seems like a docker problem though. |
We are running into a bit more esoteric issue on Windows. We use an OrientDB local instance, which writes the files to the host's file system, and on Windows it does not seem to do it. Oh... may be it is because the host volume is not block volime? |
Almost one year ago when I was trying to resolve this I found this topic. Since no any solution was provided at that time, I created a bunch of wrapping bash scripts to run your docker-compose. Now after a year it's all the same. I wonder at how much times it takes to resolve such a simple issue for a software like docker-compose which is not even a real provider but instead a wrapper. $UID is not exported on Linux by default, ok? This prevents us from creating a universal docker-compose - which is a strange thing by itself as this piece of software is assumed to be a front-end solution, right? If you guys don't like to waste time on trifles - and I understand that - then why don't you just let us to execute a random host command prior to running a service, eh? We could just do something like this: services:
web:
...
host_command: export UID Isn't that obvious? |
+1 |
This issue does not have enough likes and +1s and to me it's an overlooked yet needed and requested by a lot of users including myself. I'm here to give my +1 as well because I'm hit by this. I currently don't want my containers to run as root -yet- I want them to share a volume in the host which is writeable by my user. This can't be done if I don't set the user and expansion would be the most natural way to do this instead of Just my 2 cents. So, anybody found a way to do this anyways? |
@darkguy2008 - Be sure to hype this one up: moby/moby#22415 I suspect a feature will be needed within docker itself before compose could build on top of it. |
The link is broken. |
Found that adding a mandatory variable helped as a workaround:
Would show:
Specifying that the file has to be executed like this:
|
The problem is that my services require
|
Has this issue not been resolved yet? I just want the current user UID to be set in the container to avoid file permission issues on the host. |
I need to pass
--user
option to run orchestrated containers under my own UID. This is mostly because of mounted host volumes, and I'd like the dockerized app to generate files owned by me, not the root.With
docker-compose up
, this is not possible, at least not directly. Right now I'm using a crazy workaround:which is suboptiomal, to be gentle.
The text was updated successfully, but these errors were encountered: