Container problems on CHR

[fctech2490]

Hello everyone,
I’m having issues when trying to run the ZeroTier container in my environment.
Currently, I’m running a CHR on VMware ESXi 8.0 Update 2, and I installed the CHR by downloading the OVA file from the official MikroTik website.

When I try to deploy the container, I get a generic error, which I’ve attached a screenshot of.
Does anyone know how I can resolve this issue?

Thank you!

[fctech2490]

Anyone Does anyone have any updates regarding this issue? I’m adding another screenshot of the error from the logs to the post.

[TrevinLC1997]

What registry are you using? I was having problems importing containers on v7.17.2 with the same error. You can try updating to v7.18 beta 6. That’s what fixed it for me.

Edit - From another member of this forum it looks like due to docker hub api changes, it won’t work unless you update to 7.18.

[fctech2490]

What registry are you using? I was having problems importing containers on v7.17.2 with the same error. You can try updating to v7.18 beta 6. That’s what fixed it for me.

Edit - From another member of this forum it looks like due to docker hub api changes, it won’t work unless you update to 7.18.

Hi,
I can confirm what you reported. After upgrading to version 7.18beta6, I was able to successfully pull the zerotier/zerotier:latest and cloudflare/cloudflared:latest containers from the registry at https://registry-1.docker.io.

However, I am still experiencing issues with the alpine:latest container (https://hub.docker.com/_/alpine/tags), and in the logs, I see the error:
“[cont] error response getting manifests: 401”.

I have already opened a ticket with support to investigate this issue. That said, my priority is ensuring that ZeroTier and Cloudflare containers work correctly, rather than the Alpine container.

[tangent]

“[cont] error response getting manifests: 401”.

HTTP code 401 is “unauthorized,” which leads to us asking what you’re doing that requires authorization.

Since RouterOS can’t push layers, and this is a public repo, the only other likely reason is that you were experimenting with DH login creds and put the wrong ones in. A common error here is putting your DH password in while 2FA is enabled. You need to use an access token instead.

One excellent reason to use DH login creds even when pulling from a public repository — an action that you could instead do anonymously — is that it bypasses part of the new pull rate limits by getting you out of the “anonymous” bucket, where all the bots land.

[fctech2490]

“[cont] error response getting manifests: 401”.

HTTP code 401 is “unauthorized,” which leads to us asking what you’re doing that requires authorization.

Since RouterOS can’t push layers, and this is a public repo, the only other likely reason is that you were experimenting with DH login creds and put the wrong ones in. A common error here is putting your DH password in while 2FA is enabled. You need to use an access token instead.

One excellent reason to use DH login creds even when pulling from a public repository — an action that you could instead do anonymously — is that it bypasses part of the new pull rate limits by getting you out of the “anonymous” bucket, where all the bots land.

It seems that the issue is related to the format used to pull the container from Docker Hub. In this post Container and RouterOS v7.18 [stable] I was advised to use the format “library/:”, and this way, everything works correctly.

Unfortunately, the 401 error had sent me on the wrong way, but the problem seems to be related to the format with which the container image pull is done

[bcmdevtl]

I had the same issue trying to pull a postgres image, after adding "library/" to the remote-image it worked (tested on v7.18.2 and v7.20rc2 on my RB5009)

ERROR 401
/container/add remote-image=postgres:17 interface=veth-db mounts=pgdata envlist=pg-env logging=yes start=yes

OK
/container/add remote-image=library/postgres:17 interface=veth-db mounts=pgdata envlist=pg-env logging=yes start=yes

Hope this helps someone