unknown user: poky user

[adam-lee]

Just following the instruction on MacBook Pro 2018 w/ MacOS Mojave. I believe I have followed the steps word for word.

docker run --rm -it -v yocto-workder:/workdir crops/poky --workdir=/workdir
Unable to find image 'crops/poky:latest' locally
latest: Pulling from crops/poky
16c48d79e9cc: Pull complete 
3c654ad3ed7d: Pull complete 
6276f4f9c29d: Pull complete 
a4bd43ad48ce: Pull complete 
c3d94dbdeb70: Pull complete 
52df6c0c42bb: Pull complete 
751ac3ce3f9d: Pull complete 
db8ada821869: Pull complete 
dff7c078f160: Pull complete 
7a0fa8e2a2a4: Pull complete 
a8971d003903: Pull complete 
ea78bfaaa2fa: Pull complete 
5ec634062ee8: Pull complete 
Digest: sha256:8eefa1cef8ebc987188cada7e83a315285d099be05d7fb55451c5e2a481f2e9b
Status: Downloaded newer image for crops/poky:latest
sudo: unknown user: pokyuser
sudo: unable to initialize policy plugin

[adam-lee]

Apologies. Just a typo in my command.

[btgoodwin]

What was the typo? I'm seeing this on macOS Catalina, and so far as I can tell, your command has no typos in it.

[bearrito]

Is there any update from the original poster? I'm seeing this on Ubuntu 18.04

[rewitt1]

Hi @bearrito,

Could you post the host os you are using and the full command you are running? I'll hopefully get some time to try to reproduce the issue.

[btgoodwin]

I read a little more closely on @adam-lee's post and saw yocto-workder vs. perhaps yocto-workdir was the real directory name and tried to replicate it on my Catalina system, but I received the same error at the end:

sudo: unknown user: poyuser
sudo: unable to initialize policy plugin

FWIW, I have a CentOS 7 system here as well, so I tried the same command and corrected path as the OP:

# PWD is ~ with subdirectory yocto-workdir
[~]$ docker run --rm -it -v yocto-workdir:/workdir crops/poky --workdir=/workdir
Unable to find image 'crops/poky:latest' locally
latest: Pulling from crops/poky
5bed26d33875: Pull complete
f11b29a9c730: Pull complete
930bda195c84: Pull complete
78bf9a5ad49e: Pull complete
a946b3adf27d: Pull complete
d46479f7c2f1: Pull complete
cd006be07644: Pull complete
c135f38d1960: Pull complete
0b23f5feb836: Pull complete
c652f3b46c9f: Pull complete
bbffdf8b8a4c: Pull complete
e956ae05ef17: Pull complete
d09ecbc9a55b: Pull complete
Digest: sha256:d2c8438cecb7cb93d5de16bed61506e9af130452fe8007191c77515763912bc7
Status: Downloaded newer image for crops/poky:latest
sudo: unknown user: pokyuser
sudo: unable to initialize policy plugin

[rewitt1]

@btgoodwin, @bearrito I hopefully addressed this with https://github.com/crops/extsdk-container/commit/6e512f007829647351c50722bd4afb8472da7e1a. Your example should now error like so:

[~]$ docker run --rm -it -v yocto-workdir:/workdir crops/poky --workdir=/workdir
The uid:gid for "/workdir" is "0:0". The uid and gid must be non-zero. Please check to make sure the "volume" or "bind" specified using either "-v" or "--mount" to docker, exists and has a non-zero uid:gid.

This is basically the same type of problem as https://github.com/crops/poky-container/issues/20, but instead of docker automatically creating a directory, it is automatically creating a volume. It will do this anytime an absolute path is not specified.

If you supply an absolute path for the host-dir, Docker bind-mounts to the path you specify. If you supply a name, Docker creates a named volume by that name. [1]

If you run docker volume ls, I expect that you would see the yocto-workdir volume listed.

I may end up changing the README to show examples with --mount [2] instead of -v, since it is more explicit, won't automatically create directories and seems to allow for relative paths.

[1] https://docs.docker.com/engine/reference/run/#volume-shared-filesystems [2] https://docs.docker.com/storage/volumes/#choose-the--v-or---mount-flag

[btgoodwin]

Good point about the yocto-workdir becoming a volume name; I forgot that was the behavior, and I think I see what's going on. (That volume got created automatically on Linux but not macOS, by the way.) Summary: this can probably be closed (I realize it's already closed by the OP, I'm meaning more than those following the thread can understand a solution beyond "it was a typo.")

Back on macOS like the OP, I used a full path this time to my own workspace area, a case-sensitive volume with non-zero uid and gid at /Volumes/Linux/yocto, and still had the same result:

[~]$ docker run --rm -it -v /Volumes/Linux/yocto:/workdir crops/poky --workdir=/workdir
Unable to find image 'crops/poky:latest' locally
latest: Pulling from crops/poky
5bed26d33875: Pull complete
f11b29a9c730: Pull complete
930bda195c84: Pull complete
78bf9a5ad49e: Pull complete
d5f86077d764: Pull complete
f3bcab81149f: Pull complete
5963b6dc59fe: Pull complete
b06020422e30: Pull complete
3a9a97032945: Pull complete
4e1c4bdcee8c: Pull complete
706caac8374d: Pull complete
9e53464c29f8: Pull complete
cd0bd357a40c: Pull complete
Digest: sha256:c7c402d7bd056a26b4457068308cecffd7ad5f7e3b2f956788417fcdac7aa872
Status: Downloaded newer image for crops/poky:latest
sudo: unknown user: pokyuser
sudo: unable to initialize policy plugin

On the CentOS 7 system, the command works fine (now that I'm using the full path vs. a volume name ;-)).

I suspected this has something to do with the VM inception going on with the macOS environment to get Docker going, which led to these discoveries. First, I ran the above command for just centos:7 and confirmed the internally-mounted volume is as root because of the resulting osxfs mount permissions, as described in this post (which sadly has no solution for file system mounts vs. docker volumes...next). Second, I found a separate issue indicating this is as designed, and then third, remembered the extra steps here.

Going back and creating the volume, changing its ownership to the host user, and then re-running crops works as designed:

[~]$ docker volume create --name yocto-volume
[~]$ docker run -it --rm -v yocto-volume:/workdir busybox chown -R $(id -u):$(id -g) /workdir
[~]$ docker run --rm -it -v yocto-volume:/workdir crops/poky --workdir=/workdir
pokyuser@156aeb30e78b:/workdir$

Hopefully our problem trace-out will help others, though I'm disappointed (with docker mac) that this is the solution since the Docker VM size will have to be large to support a yocto volume.

FWIW, on a different project, I was running into problems with hard links not being supported on macOS NFS or samba, so I couldn't simply mount those volumes to my container, using macOS as the file server (yeah, performance would have been horrific for Yocto, that project was small though). I also tried Parallels volume mounts, but those also have problems with hard links (this specific thing would break some compile jobs). Ultimately I used OSXFuse and SSHFS within the VM/container to mount folders stored on macOS. This has been working, but I would put money on it that the performance at scale (Yocto) will be awful. (Also, upon installing OSXFuse, macOS warns you the extension will be obsolete in future releases ...so this is a bandaid).

[btgoodwin]

This got me thinking. The CROPS containers hand off to the worker user upon entry, so the container actually starts as root. I have a container I use for CentOS development that uses ARG at build time to configure the user to the external UID and GID, and then it only runs as that user (terrible solution for this, hear me out...). I tried all the above using it, and sure enough, the osxfs mount is now owned not by root but by that internal user (which maps to my external user).

Maybe there is a way around this quirk that doesn't involve storing the yocto volume inside the Docker VM.

[thirtythreeforty]

I have hit this same problem and I am still confused about the underlying cause. On macOS Catalina, if I run:

docker run --rm -it -v /Users/myself/my-workdir:/workdir crops/poky --workdir=/workdir

(note the absolute path being mounted, not a volume), then I get the originally-reported error message.

But if instead I omit --workdir, the container launches with /workdir mounted, and I can see that it has the "magic permissions" behavior of osxfs.

docker run --rm -it -v /Users/myself/my-workdir:/workdir crops/poky

I'm not sure Docker is at fault here, as much as I hate to say it. It seems like one of the scripts in the image is emitting the error, not (necessarily) related to the volume mounting.

Could someone better explain the root cause to me?

[rewitt1]

Hi @thirtythreeforty,

The poky-container dynamically creates a user based on the uid:gid of the workdir. Here is how that process works.

Poky container user creation

1. Container starts as user usersetup uid=70 gid=70
2. Container checks the uid:gid of the workdir(let's say it's 2000:3000)
3. Container creates a user called pokyuser with the uid:gid 2000:3000
4. Container starts running as pokyuser

If --workdir is not specified, the workdir defaults to /home/pokyuser and a uid:gid of 1000:1000.

The idea was that a user could easily test out / use the containers without having to hard code a uid:gid and rebuild the container.

osxfs differences

osxfs evidently changes the uid/gid of a file to be that of the currently active user, unless a container process modifies the uid/gid of said file (osxfs ownership). So this is what happens:

1. Container starts as user usersetup 70:70
2. Container checks the uid:gid of the workdir(in this case 70:70)
3. Container doesn't try to create user, because 70:70 already exists
4. Container tries to run as pokyuser, but can't because it never got created

When you omit the --workdir it creates a user using 1000:1000 and files still get created in the /workdir osxfs with appropriate permissions due to the ownership mappings linked to earlier.

As a workaround you could also manually specify whatever uid:gid you like and it will ignore the uid:gid of the workdir when creating pokyuser: % docker run -it --rm -v `pwd`/foo:/workdir deleteme:ubuntu-18.04 --id _someuid_:_somegid_ --workdir=/workdir

Bug

So the bug appears to be that although we don't create the user, we also don't replace the username. However this isn't something that is expected to happen because osxfs is essentially masking the real ownership of the files. However, this behavior can easily be reproduced in Linux by running:

% sudo chown -R 70:70 foo
% docker run -it --rm -v `pwd`/foo:/workdir deleteme:ubuntu-18.04 --workdir=/workdir
sudo: unknown user: pokyuser
sudo: unable to initialize policy plugin

It's a legitimate bug and something that should be fixed.

Background of why samba was used and note regarding osxfs

Using a volume exposed via samba was chosen due to the fact that the behavior is consistent between platforms, performant and guaranteed to support the filesystem features that a Yocto build requires.

While fixing the bug would allow for specifying the --workdir when using osxfs in the same manner as using a volume, I have never tried it and am unsure of what other issues may arise due to using osxfs. And I can't guarantee I would have much time to investigate osxfs specific issues.

--Edit I just wanted to clarify. If osxfs is useful to people even with potential caveats, I am not against accepting pull requests that may help that functionality. I do not personally use osxfs, nor actively develop on a macbook. However, I am in no way against the support and don't want to seem to be discouraging it.

[thirtythreeforty]

Awesome answer, thanks. Yes, osxfs support would be useful to me, however its bizarre behavior makes it totally understandable that it doesn't Just Work in this kind of case.

[juanrh]

I tried the workaround for MacOS, and I get the error described on https://github.com/crops/poky-container/issues/20. So +1 on this one