Subject: (permission_denied) write_package Error in GitHub Actions and Missing GHCR Package After Repository Recreations

[sbksba]

Why are you starting this discussion?

Question

What GitHub Actions topic or product is this about?

Misc

Discussion Details

Hello,

I'm encountering a persistent issue with pushing Docker images to GitHub Container Registry (GHCR) from my personal account (sbksba). I also can't see the pushed packages in the GitHub UI, even after successful docker push commands from my local machine.

Here's a detailed breakdown of the problem:

1. Context:

   My GitHub account username is sbksba.

   The repository in question is weekly-task-manager.

   Initially, when I first set up this repository and its GitHub Actions workflow, everything worked correctly: Docker images were built and pushed to ghcr.io/sbksba/weekly-task-manager without issues.

   However, I've had to delete and recreate this weekly-task-manager repository multiple times for various reasons (always using the exact same name). Since the first recreation, I've been unable to successfully push images via GitHub Actions, and I can no longer see the packages on GHCR.

2. Problem in GitHub Actions:

   My GitHub Actions workflow (.github/workflows/release.yml) for weekly-task-manager is configured with permissions: packages: write.

   Despite this explicit permission, the "Build and push Docker image" step consistently fails with the error: denied: permission_denied: write_package.

   I understand this often relates to token permissions, but the workflow clearly states write access, and it previously worked.

[tw181802]

Howdy, sounds like GHCR's trippin' after you nuked and re-created the repo.

Even if the repo name’s the same, GHCR sees it as a fresh one — so the old package permissions probably don’t line up anymore. That permission_denied: write_package error usually means your GitHub Actions token doesn’t have rights to push to GHCR for that new repo.

Quick checks:

Make sure your workflow has permissions: packages: write and contents: read at the top.

If you're using GITHUB_TOKEN, remember it's scoped per repo — so if the package still exists from before, GHCR might be blocking access.

Try deleting the old package manually from https://github.com/users/sbksba/packages if it’s still hangin’ around.

Worst case, try pushing once manually with a PAT that has write:packages scope, just to reset the registry link.

GHCR can be a bit picky with repo recreations. Once it’s reset clean, the Actions push should work again.

[sbksba]

Hey there,

Just wanted to send a quick note to say thanks a ton for your help!

You totally nailed it. Turns out the problem was indeed those old, lingering packages chilling in GHCR from my previous repo versions. Even though my local docker push looked like it worked, the UI wasn't showing anything, and GitHub Actions kept hitting that wall because of those stale entries.

Once I manually nuked the old weekly-task-manager package from https://github.com/users/sbksba/packages like you suggested, everything just clicked! My GitHub Actions workflow is now running smoothly, and the Docker image finally shows up in GHCR.

Seriously, that's one "picky" part of GHCR, but your insight was spot-on.

[Sanjith77]

Quickly check this and see

Make sure your workflow has permissions: packages: write and contents: read at the top.

If you're using GITHUB_TOKEN, remember it's scoped per repo — so if the package still exists from before, GHCR might be blocking access.

Try deleting the old package manually from https://github.com/users/sbksba/packages if it’s still hangin’ around.

Worst case, try pushing once manually with a PAT that has write:packages scope, just to reset the registry link.

A bit picky with repo recreations. Once it’s reset clean, the Actions push should work again.