[nickjj]

> Are you saying that all files from your containers are owned by you as user? If so I will start investigating right now

You can do this with Docker today without much fuss.

Here's a bunch of web app examples (Flask, Rails, Django, Node, Phoenix) that run your containers as a non-root user which ensures any volume mounted files end up being set to your Docker host's user along with running your main process as a non-root user: https://github.com/nickjj?tab=repositories&q=docker-*-exampl...

There's no hard coding of user names either. The user name created in the Docker image never directly gets mapped back to your Docker host.

This works because bind mounts happen over uid:gid 1000:1000 by default, so as long as your Docker host user's uid:gid is 1000:1000 everything works out of the box. On Windows and macOS you don't need to even think about this because Docker Desktop will fix permissions for you and on native Linux chances are your user uid:gid is 1000:1000 because it's the first non-root user on your system. For non-controllable environments like CI you'd typically disable volumes which is a good idea anyways because you're probably not using volumes in production. For single server deploys on a self managed VPS you control the environment. I covered this in a little more detail in my DockerCon talk at: https://nickjanetakis.com/blog/best-practices-around-product...

In the worst case scenario where you have no other options you can make the Dockerfile more complicated and introduce build args for the uid:gid so you can change it to satisfy the needs of a specific host but I don't like this since you'd need to rebuild a different image for a different environment, but it would technically work. I've never run into this scenario after having used Docker since 2014. I've also done contract work for dozens of companies in all sorts of different environments.

[zbentley]

That's fair, but that issue is more common than you think. Some folks use Linux desktop systems with multiple users: shared computers (family or university--not all lab environments have sane workstation user management, unfortunately), or a personal computer with multiple accounts for separation (e.g. a home and work user) both come to mind.

And sure, UID remapping is available, but that's no longer in the realm of "just works".

[nickjj]

You can perform the step in my last paragraph to make it work in those cases. It would come down to introducing 2 new build args, making sure the user you create sets the uid:gid based on these values, defaulting to 1000:1000 so it works for most but allows you to override them by modifying 2 env variables in an .env file (you can configure docker-compose to set the build args with env vars).

If someone has a case where they are doing anything you described the above steps can be implemented in like 5 lines of code and 5 minutes. I didn't add it to my example apps because there's only been 1 or 2 requests for it over multiple years and I've never encountered it once, no one taking my Docker courses has ever hit a road block by it either.