Skip to main content

​
Certificate errors (corporate proxy)

If you encounter an SSL/TLS error when trying to pull the image from docker, this may be caused by a corporate proxy on your local network. Popular corporate proxies include Zscaler Secure Internet Access (ZIA), FortiGate, Prisma Access and others. Examples of common errors caused by a corporate proxy:
  • x509: certificate signed by unknown authority
  • connection reset by peer
  • TLS handshake timeout
To fix the problem: Pull from a cloud VM that isn’t impacted by firewall inspection to circumvent the issue. Updating the certificates on your local PC is generally harder because you would need to obtain the custom CA.

​
Cached image is out of date

To fix the problem: Use the --pull flag with the docker build command or --pull always with docker run to force Docker to pull the latest image digest even if the version tag is the same. To force Docker to pull the image even if an image with the same tag already exists locally: 
docker run --pull always {image}
Explanation: Minimus images can potentially be rebuilt every day. As a result, the same image version tag may have numerous image digests. Many times, vulnerabilities fixes are delivered without the image version tag changing so it’s particularly important to always pull the most recent digest. See for example the Minimus digest-history for python version 3.13.5

​
Valid inline token returned unauthorized error

To fix the problem: Run docker logout reg.mini.dev to reset your access and try the pull command again. Explanation: Most likely, you previously authenticated with the docker login command and the token has since expired or been deleted. The token from the docker login command takes precedence over the inline token and this is causing the error.

​
Error logs not returned by grep

To fix the problem: Add 2>&1 flag to docker logs command. For example:
for 2>&1 flag
docker logs {container_name_or_ID} 2>&1 | grep "{search_term}"
Explanation: 2>&1 combines the standard error stream and output stream, so both are passed together to the pipe (|) and processed by grep.

​
Package built by older compiler version

The issue may be a false-positive. If the latest package version was built with the most recent compiler version available at the time, the package is up to date. Compiler updates will only trigger a package rebuild if there is an impact to the security posture - that is, if new vulnerabilities are detected in the previous compiler version. Example: The mongo-tools package is built with Go. If you run a version check it will look like this: 
/ $ mongodump --version
mongodump version: 100.13.0
git version: 23008ff975be028544710a5da6ae749dc7e90ab7
Go version: go1.25.1
   os: linux
   arch: amd64
   compiler: gc
The Go version may not be the latest anymore. At the time that the mongo-tools package version 100.13.0 was built, Go version go1.25.1was the latest available. A package build using the latest Go will be manually triggered by the Minimus team when new vulnerabilities fixes are available for the Go compiler.

​
Artifactory remote repository sync

When setting up a self-hosted registry with JFrog Artifactory, you may encounter a 401 or 403 error response from GitHub when testing the connection in the Artifactory UI. Explanation: This is a known UI issue reported by JFrog and it can be safely ignored. The sync functionality will work correctly, and you will be able to pull images from the Minimus registry into your own registry without any problems. Refer to the original report by JFrog for more details
Last modified on January 28, 2026