error running `/usr/bin/newuidmap' ; target process is owned by a different user

[Pranavbalu]

Error while trying to run docker-compose using podman from jenkins.
I've added jenkins user to subuid and subgid.

newuidmap: Target process 3832557 is owned by a different user: uid:696124 pw_uid:696124 st_uid:696124, gid:675 pw_gid:10 st_gid:675\n"
time="2022-08-03T06:37:24Z" level=error msg="invalid internal status, try resetting the pause process with "/usr/bin/podman system migrate": cannot setup namespace using "/usr/bin/newuidmap": exit status 1"

Podman Version: 4.0.2

cat /etc/subgid
jenkins:2966608:65536

$ cat /etc/subuid
jenkins:2966608:65536

id -un 696124
jenkins

When the command is directly executed from CLI
/usr/bin/newuidmap 3832557 0 696124 1 1 2966608 65536
newuidmap: Could not open proc directory for target 3832557

podman unshare cat /proc/self/uid_map
0 1596188 1
1 231072 65536

[rhatdan]

@giuseppe PTAL

[katiecrochet]

@Pranavbalu did you ever figure out how to resolve this issue? i am experiencing the exact same error. have tried removing ~/.local/share/containers with no avail, uid mapping appears to be correct as well.

[katiecrochet]

@giuseppe given what the user has said above do you know what they should/have done to fix the issue?

[giuseppe]

are you also running under jenkins?

[giuseppe]

I am not familiar with the way jenkins sets its environment to know what is going on here

[ahstram]

We had a similar issue... in our case, it turns out that we had our user jenkins defined through Active Directory, but the group jenkins was defined locally in /etc/group. jenkins user was not actually a member of the jenkins group.

This bug was particularly confusing as I was able to run podman just fine when logged in interactively as user jenkins, but it would fail out when running through the web server.

We were able to get podman working again by editing the /usr/lib/systemd/system/jenkins.service file, to change the Group= specification to an Active Directory group that our Active Directory user jenkins is actually a member of.

It is worth mentioning this issue only cropped up after updating to Jenkins 2.452.3. With older versions (unfortunately I do not have documented which, exactly), there were no issues running podman.