"unauthorized" error when pushing images

Hi,

I have succeeded on pushing images to ghcr.io under an org when logged-in as an org owner, but when logged-in as just an org member docker push just returns unauthorized.

This org’s setting Member privileges -> Package creation is already set to Public, and the PAT I’m using already has the write:packages permission.

Any idea what could be going on?

Thanks!

Hello!

Have you configured access for the organization member? The owner who created the Container would have admin permissions by default. However the org member would need to have write access added through the container settings.

Lemme know if that works!

Thanks for the feedback @clarkbw, that worked :+1:

So, if I understood correctly, only org owners can create images, and then they should grant access to other members in order for them to be able to push other tags for those images.

If I got that correct, then the description under the org’s Member privileges -> Package creation “Members will be able to create public packages, visible to anyone” can be a little misleading :wink:

Thanks again!

Any org member can create an image. That creator holds admin for the image name and can extend it to others. Sorry I was describing your circumstance.

I am seeing unauthorized when publishing a new container to ghcr.io/org-a, which I am a member of. The same personal access token, with write:packages, is authorized and able to publish for ghcr.io/org-b, which I am an owner of.

I have looked and the documentation and forums and I see lots of information on how to adjust permissions for already created images.

@clarkbw can you clarify how an org member (non-owner) can push/create new images to ghcr.io in the org namespace?

Can you share the exact error?

Any org member can currently publish packages to the organization. However there is a setting for organizations that allow containers to be published at all. See https://docs.github.com/en/free-pro-team@latest/packages/getting-started-with-github-container-registry/enabling-github-container-registry-for-your-organization

1 Like

Sure, my terminal output is below (actual org name changed to org-a for privacy). I re-tagged the latest NodeJS container for my organization, logged out of ghcr.io, logged in with a personal access token that has the write:packages scope and attempted to push the container.

I am a member of the GitHub org but I am not an org owner.

ataylor ~ » docker tag node:latest ghcr.io/org-a/my-team-prefix/spark-node-test:0.0.1 
ataylor ~ » docker logout ghcr.io
Removing login credentials for ghcr.io
ataylor ~ » docker login ghcr.io
Username: ataylorme                                        
Password: 
Login Succeeded
ataylor ~ » docker push ghcr.io/org-a/my-team-prefix/spark-node-test:0.0.1 
The push refers to repository [ghcr.io/org-a/my-team-prefix/spark-node-test]
b9914fd725cf: Mounted from node:latest 
fb9a98332674: Mounted from node:latest 
c9b47a3c6380: Mounted from node:latest 
8211c12c1c23: Mounted from node:latest 
1d3ec06e3d4f: Mounted from node:latest 
9e5330403dba: Mounted from node:latest 
8bd20dc0b7e5: Mounted from node:latest 
94b70b410c2a: Mounted from node:latest 
3567db1eb737: Mounted from node:latest 
denied: permission_denied: create_package

Are you sure the organization has turned on the setting required for GHCR?

1 Like

That setting was not enabled. It is now (thanks for the link) and I am able to push a container to ghcr.io!

@clarkbw is there a way to have newly created containers on the GitHub container registry read by default? My goal is to have them be private within our organization but still allow any org member to use the container without having to be explicitly added each time we create a new container.

If there is not a way to do that by default is there an API I can use to grant teams or users access to containers published to ghcr.io?

We’re working on an “internal” visibility setting that be the new default for images. Internal would mean all org members have read-access by default.

1 Like

That is great news, thank you @clarkbw!

1 Like

Thanks for your support here!