When building a container, we create a user account to be able to carry out the execution under an unprivileged user. For that, we use the running process' UID/GID pair. However, that assumes the UID/GID pair is a user account (IDs >= 1000) and as such does not exist in the container a priori. That assumption is false for OSX users, however, as their UID/GID combos come with IDs <= 1000.
We need to check the IDs before using them.
While this does work for running the service inside the container and testing, it represents potential issues for updating the deploy repository because the directory is mounted directly in the container. So simply adding a new user with UID=1000 would lead to potential permission problems on your local disk.
Hmm, would it be easier if I changed my user ID to > 1000 on my host machine?
I found https://www.inteller.net/notes/change-user-id-on-snow-leopard, which sounds a bit of work but promising nonetheless.
Yes, that would completely unblock you on this front. Note that you would need to change both your UID and GID (currently your GID, 20, coincides with a system group in Debian).
Hmm, I've got an my Ubuntu 14 VirtualBox image on my Mac. I guess I'll just use that although I'm not keen on doing the Inception thing (virtual machine inside another one).
What you can do is share the source code directory with the VM so that you can do the development there and testing in the VM. That will also allow you to easily update the deploy repo, as you don't really need to have it on your host.
although I'm not keen on doing the Inception thing (virtual machine inside another one).
Heh, it's not really like that. Containers are not VMs in that they run on the same kernel as the host. You can think of them as chroot on steroids :)
What you can do is share the source code directory with the VM
I've ran into issues with that. I think it was not able to create symlinks or similar. Maybe I didn't mount it correctly?
sudo mount -t vboxsf -o uid=1000,gid=1000 deploy /home/bbb/code
Anyways, I've just did fresh clones inside the VM, which I just use for updating the deploy repo. It's a bit cumbersome but works. So'm ok lowering the priority on that.
Full details of my setup are here: https://www.mediawiki.org/wiki/Wikimedia_Apps/Team/RESTBase_services_for_apps/Ubuntu_setup_notes
I've made a PR for service-runner https://github.com/wikimedia/service-runner/pull/113 that should solve this problem on Mac (if you also install the latest beta native docker for mac)
The new version of service-runner has been released. Starting from version 2.0.6 you can build the deploy repository straight from your Mac without using the VM. Although, you need to install Docker for Mac 1.12.0+, docker-machine is still not supported an will never be.
Docker for mac: booo as it requires a newer mac os. But yes, i get it, no need to support native docker and the vm.
It's not even 'no need to support' case, but 'almost impossible to support'. The problem with permissions is well-known and there's no clear way to avoid it in docker-machine setup unfortunately.