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
just joined
- Posts: 7
- Joined:
Container problems on CHR
You do not have the required permissions to view the files attached to this post.
Last edited by fctech2490 on Sat Feb 15, 2025 12:20 am, edited 1 time in total.
-
-
fctech2490
just joined
- Posts: 7
- Joined:
Re: Zerotier container problems
Anyone Does anyone have any updates regarding this issue? I’m adding another screenshot of the error from the logs to the post.
You do not have the required permissions to view the files attached to this post.
-
-
TrevinLC1997
just joined
- Posts: 22
- Joined:
Re: Container problems on CHR Topic is solved
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.
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
just joined
- Posts: 7
- Joined:
Re: Container problems on CHR
Hi,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.
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.
Re: Container problems on CHR
"[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
just joined
- Posts: 7
- Joined:
Re: Container problems on CHR
It seems that the issue is related to the format used to pull the container from Docker Hub. In this post viewtopic.php?t=215086, I was advised to use the format "library/<repository>:<tag>", and this way, everything works correctly."[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.
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