Hacker News new | ask | show | jobs
by q3k 1844 days ago
> IMO it's really rare that your dev box's user wouldn't be 1000:1000 on native Linux or WSL 2.

Any company-wide (GNU/)Linux deployment that uses LDAP or some other centralized user directory will not have devs with UID/GID 1000:1000. Hope is not a strategy.

1 comments

> 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.

> 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.

> 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.