img pull error failed to mount unmount /tmp/containerd-mount...
Installed img from source on Debian 10 (golang:1.13.12-buster). Running the container with the --privileged flag to test.
img version
img:
version : v0.5.10
git hash : 38b683a6
go version : go1.13.12
go compiler : gc
platform : linux/amd64
runc:
version : 1.0.0-rc10+dev
commit : 56aca5aa50d07548d5db8fd33e9dc562f70f3208
spec : 1.0.2
Running img login appears to work... at least I get "Login succeeded." Running img pull python:slim-buster (for instance) returns the following error:
Pulling python:slim-buster...
Error: failed to unmount /tmp/containerd-mount315526853: operation not permitted: failed to mount /tmp/containerd-mount315526853: operation not permitted
I'm guessing there's a step I'm missing somewhere, but no idea where. My eventual intent is to deploy as part of a Kubernetes service, but testing from local for now.
Also, kudos for the tool in general (issue notwithstanding). Definitely a needed addition!
Issue-Label Bot is automatically applying the label bug to this issue, with a confidence of 0.88. Please mark this comment with :thumbsup: or :thumbsdown: to give our bot feedback!
Links: app homepage, dashboard and code for this bot.
FWIW, if I start from golang:1.13.12-alpine3.12, and follow the README installation instructions for Alpine it works.
Update: Can run it in a container from local, but having trouble deploying as a job on K8s. The pod spec has the annotations. I'm running in AWS EKS with Kubernetes v 1.16
Job Pod Spec YAML metadata
apiVersion: batch/v1
kind: Job
metadata:
name: test-create
namespace: <namespace>
annotations:
container.apparmor.security.beta.kubernetes.io/img: unconfined
container.seccomp.security.alpha.kubernetes.io/img: unconfined
chmod fix
I have included the chmod at the end of the dockerfile of the img container as suggested in a different issue like so:
RUN apk add img
RUN chmod u-s /usr/bin/new[gu]idmap && \
setcap cap_setuid+eip /usr/bin/newuidmap && \
setcap cap_setgid+eip /usr/bin/newgidmap
# Give non-root users full control over the runc state folders. In non-container environments - use groups instead of the 777 permission.
RUN mkdir -p /run/runc && chmod 777 /run/runc
Job commands
The commands of the job are, essentially:
$ img login
$ img pull <image-repo:tag>
$ img build -f /tmp/dockerfile -t <different-repo:new-tag> .
$ img push <different-repo:new-tag>
Failed to mount containerd error
I get "Login succeeded", but more or less the same error message I got earlier with the buster img build. I'm not sure how to go about unmasking procfs, if that would help...
Login succeeded.
Pulling <image-repo:tag>...
Error: failed to unmount /tmp/containerd-mount058187076: operation not permitted: failed to mount /tmp/containerd-mount058187076: operation not permitted
Building docker.io/<different-repo:new-tag>
Setting up the rootfs... this may take a bit.
time="2020-06-11T13:14:39Z" level=warning msg="Process sandbox is not available, consider unmasking procfs: "
time="2020-06-11T13:14:39Z" level=warning msg="using host network as the default"
#2 [internal] load build definition from dockerfile_update
#2 transferring dockerfile: 179B done
#2 DONE 0.0s
#1 [internal] load .dockerignore
#1 transferring context: 2B done
#1 DONE 0.0s
Error: failed to solve: failed to solve with frontend dockerfile.v0: failed to read dockerfile: failed to mount /tmp/buildkit-mount113137230: [{Type:bind Source:/root/.local/share/img/runc/native/snapshots/snapshots/3 Options:[rbind ro]}]: operation not permitted
Issue-Label Bot is automatically applying the label
bugto this issue, with a confidence of 0.88. Please mark this comment with 👍 or 👎 to give our bot feedback!Links: app homepage, dashboard and code for this bot.
Down voting as I doubt this is a bug with img, but rather a question for how to effectively deploy with K8s.
I got the same issue with local Docker runs.
Got the same issue in my CI
The same issue with version v0.5.11
I am running this with v0.5.11 and got the same issue on an Ubuntu 20.4 based pod within AKS. I already have the unconfined annotations as above. The only way so far to make this work is to run the pod in privileged mode.