I had with an issue with files in a volume being created by users in the container that don't exist on the host. I was trying to figure out if this fixes that issue, and if so how? I played around with it for an afternoon but left confused.
Use case:
Using compass within a container for development
Compass creates sass files with whatever user it run under within the container (likely root)
Host must chmod them to do stuff with them
As a work around, I've been building images and creating a user:group that matches my host. Obviously this destroys portability for other developers.
In unix, a uid is just an integer (chown <random_int> file will work). In your case, the container created a file in a volume with a uid. This uid makes no sense on host but it leaks out to host anyway since it's a 'volume'.
I think with the userns map, you can map container uid to a host uid. The files created in the volume will then be visible on the host as the mapped uid.
This is my understanding, I have to play with it :-)
I think the canonical way (at least a while ago) was to only manipulate volumes using containers. There might be other solutions available now but this one seems to be the easiest, as it does not require to change the permissions or ownership on the files/volumes being manipulated.
I think I might have caused a misunderstanding of the issue (I was trying to be brief). It really doesn't matter who I'm running compass as (root or otherwise), the issue is that the container is writing files to my host with a different UID:GID then the one I'm using on my host machine.
I wouldn't normally run compass as root, it was incidental to the actual issue.
Use case:
Using compass within a container for development
Compass creates sass files with whatever user it run under within the container (likely root)
Host must chmod them to do stuff with them
As a work around, I've been building images and creating a user:group that matches my host. Obviously this destroys portability for other developers.