[nickjj]

> Any company-wide (GNU/)Linux deployment that uses LDAP...

You can go the extra mile and turn the UID:GID into build args like the original parent and you're good to go. No hacks necessary, and since it's all self contained into a .env file there's nothing extra you need to run since you're likely using an .env file already for other vars.

Alternatively you could do this: https://news.ycombinator.com/item?id=27344491

In either case you can solve the problem without too much effort.

[q3k]

> You can go the extra mile and turn the UID:GID into build args like the original parent and you're good to go.

That doesn't help you if you're attempting to use pre-built/existing Docker images that are not built internally and make the assumption that “1000:1000 is good enough”. You then not only have to hack around Docker limitations, but also around someone else's broken assumption.

[nickjj]

> That doesn't help you if you're attempting to use pre-built/existing Docker images that are not built internally

Most pre-built images that I've come across don't require bind mounts to function.

Images like PostgreSQL aren't affected by this because you can use a named volume, and most pre-built applications that are shipped as images tend to store their state in a database and don't require bind mounts to function.