unauthorized: reqpackageaccess when pushing to container registry

[gilgoolon]

Description

I setup a fresh Gitea installation trying to push my docker image to the user docker regsitry.
I get the following error:

The push refers to repository [<domain><user><image_name>]
efafae78d70c: Preparing 
unauthorized: reqPackageAccess

And the logs show something like this (I copied this from another thread but its the same log):

2024/07/07 08:32:03 ...eb/routing/logger.go:102:func1() [I] router: completed POST /v2/dlmw/minecraft/blobs/uploads/ for 10.0.0.2:0, 401 Unauthorized in 1.1ms @ packages/api.go:42(packages.ContainerRoutes.func2.1.reqPackageAccess.4)
2024/07/07 08:32:03 ...eb/routing/logger.go:102:func1() [I] router: completed POST /v2/dlmw/minecraft/blobs/uploads/ for 10.0.0.2:0, 401 Unauthorized in 1.1ms @ packages/api.go:42(packages.ContainerRoutes.func2.1.reqPackageAccess.4)

I saw #31531, scanned for all related issues and disocrd messages, and it seems this was solved for everyone by using a PAT, or turned out to be a proxy issue.

I have tried the following:

• using a PAT with all or some permissions (with packages read/write)
• logging as a different account
• logging as an admin account
• enabling all sorts of settings in the gitea configuration
• enabling all sorts of settings in the nginx configuration
• reading the documentation
• reinstalling 3 different gitea version
• using MySQL instead of Sqlite
• using docker-compose instead of snap

All of the above yielded the exact same error.
Its worth noting that everything else works flawlessly, I got up an action runner working etc...

When I disable my reverse proxy entirely (and modify the gitea configuration accordingly) and try to push directory to localhost docker refuses to cooporate since it requires https.

Here are my current configurations:
/var/snap/gitea/common/conf/app.ini

APP_NAME = ...
RUN_USER = root
WORK_PATH = /var/snap/gitea/common
RUN_MODE = prod

[database]
DB_TYPE = mysql
HOST = 127.0.0.1:3306
NAME = giteadb
USER = gitea
PASSWD = ...
SCHEMA = 
SSL_MODE = disable
PATH = /var/snap/gitea/common/data/gitea.db
LOG_SQL = false

[repository]
ROOT = /var/snap/gitea/common/data/gitea-repositories

[server]
SSH_DOMAIN = localhost
DOMAIN = localhost
HTTP_PORT = 3000
ROOT_URL = http://domain.com/
APP_DATA_PATH = /var/snap/gitea/common/data
DISABLE_SSH = false
SSH_PORT = 22
LFS_START_SERVER = true
LFS_JWT_SECRET = m9CFrRAuU1LR4RCFsQRgP2BdE9kpnqRaJVB_Oxv28zU
OFFLINE_MODE = true

[lfs]
PATH = /var/snap/gitea/common/data/lfs

[mailer]
ENABLED = false

[service]
REGISTER_EMAIL_CONFIRM = false
ENABLE_NOTIFY_MAIL = false
DISABLE_REGISTRATION = false
ALLOW_ONLY_EXTERNAL_REGISTRATION = false
ENABLE_CAPTCHA = false
REQUIRE_SIGNIN_VIEW = false
DEFAULT_KEEP_EMAIL_PRIVATE = false
DEFAULT_ALLOW_CREATE_ORGANIZATION = true
DEFAULT_ENABLE_TIMETRACKING = true
NO_REPLY_ADDRESS = noreply.localhost

[openid]
ENABLE_OPENID_SIGNIN = true
ENABLE_OPENID_SIGNUP = true

[cron.update_checker]
ENABLED = false

[session]
PROVIDER = file

[log]
MODE = console
LEVEL = info
ROOT_PATH = /var/snap/gitea/common/log

[repository.pull-request]
DEFAULT_MERGE_STYLE = merge

[repository.signing]
DEFAULT_TRUST_MODEL = committer

[security]
INSTALL_LOCK = true
INTERNAL_TOKEN = ...
PASSWORD_HASH_ALGO = pbkdf2

[oauth2]
JWT_SECRET = ...

I tried directlly curling the docker api directly (via the proxy), with an authorization header (-u :) every time, and it worked, that way I can upload a package.

This points to the nginx configuration hiding some header or something, but when I sniff it with wireshark it seems like all the headers are there (this is after a successful login request):

POST /v2/username/image/blobs/uploads/ HTTP/1.0
Host: domain.com
X-Real-IP: 127.0.0.1
X-Forwarded-For: 127.0.0.1
X-Forwarded-Proto: https
Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJleHAiOjE3NzM3NDAzNjMsIm5iZiI6MTc3MzY1Mzk2MywiVXNlcklEIjotMSwiU2NvcGUiOiIifQ.PCVoCvG1bTUtG-dD9LA47koYWBuNV5UPk11Oqlqm3qU
Connection: close
Content-Length: 0
User-Agent: docker/29.3.0 go/go1.25.7 git-commit/83bca51 kernel/6.17.0-19-generic os/linux arch/amd64 UpstreamClient(Docker-Client/29.3.0 \(linux\))
Accept-Encoding: gzip


HTTP/1.0 401 Unauthorized
Content-Type: text/plain; charset=utf-8
Www-Authenticate: Basic realm="Gitea Package API"
X-Content-Type-Options: nosniff
Date: Mon, 16 Mar 2026 09:39:23 GMT
Content-Length: 17

reqPackageAccess

here is my nginx configuration (tried multiple, but this is what I landed on):

server {
    listen 80;
    server_name domain.com;
    # Redirect all HTTP traffic to HTTPS
    return 301 https://$host$request_uri;
}

server {
    listen 443 ssl;
    server_name domain.com;

    ssl_certificate /etc/nginx/ssl/domain.crt;
    ssl_certificate_key /etc/nginx/ssl/domain.key;

    client_max_body_size 0; 
    chunked_transfer_encoding on;

    location / {
        proxy_pass http://localhost:3000; # Or your internal Gitea IP
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        
        proxy_redirect off;
        proxy_buffering off;
        proxy_set_header Authorization $http_authorization;
        proxy_pass_header Authorization;
    }

    location /v2 {
        proxy_set_header Host $host;

        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;

        proxy_set_header Authorization $http_authorization;
        proxy_pass_header Authorization;

        proxy_pass http://localhost:3000;
        proxy_read_timeout 900;
    }
}

I may have forgot to mention a few things I tried, but this is getting too long so just ask if you need more info..

Gitea Version

1.25.4

Can you reproduce the bug on the Gitea demo site?

No

Log Gist

No response

Screenshots

No response

Git Version

No response

Operating System

Ubuntu 24.04

How are you running Gitea?

systemd (installed via snap)

Database

SQLite

[wxiaoguang]

Your access token lacks "packages" permission.

gitea/routers/api/packages/api.go

Lines 43 to 80 in 79f96b3

	scope, ok := ctx.Data["ApiTokenScope"].(auth_model.AccessTokenScope)
	if ok { // it's a personal access token but not oauth2 token
	scopeMatched := false
	var err error
	switch accessMode {
	case perm.AccessModeRead:
	scopeMatched, err = scope.HasScope(auth_model.AccessTokenScopeReadPackage)
	if err != nil {
	ctx.HTTPError(http.StatusInternalServerError, "HasScope", err.Error())
	return
	}
	case perm.AccessModeWrite:
	scopeMatched, err = scope.HasScope(auth_model.AccessTokenScopeWritePackage)
	if err != nil {
	ctx.HTTPError(http.StatusInternalServerError, "HasScope", err.Error())
	return
	}
	}
	if !scopeMatched {
	ctx.Resp.Header().Set("WWW-Authenticate", `Basic realm="Gitea Package API"`)
	ctx.HTTPError(http.StatusUnauthorized, "reqPackageAccess", "user should have specific permission or be a site admin")
	return
	}
	// check if scope only applies to public resources
	publicOnly, err := scope.PublicOnly()
	if err != nil {
	ctx.HTTPError(http.StatusForbidden, "tokenRequiresScope", "parsing public resource scope failed: "+err.Error())
	return
	}
	if publicOnly {
	if ctx.Package != nil && ctx.Package.Owner.Visibility.IsPrivate() {
	ctx.HTTPError(http.StatusForbidden, "reqToken", "token scope is limited to public packages")
	return
	}
	}
	}

[gilgoolon]

Your access token lacks "packages" permission.

gitea/routers/api/packages/api.go

Lines 43 to 80 in 79f96b3

	scope, ok := ctx.Data["ApiTokenScope"].(auth_model.AccessTokenScope)
	if ok { // it's a personal access token but not oauth2 token
	scopeMatched := false
	var err error
	switch accessMode {
	case perm.AccessModeRead:
	scopeMatched, err = scope.HasScope(auth_model.AccessTokenScopeReadPackage)
	if err != nil {
	ctx.HTTPError(http.StatusInternalServerError, "HasScope", err.Error())
	return
	}
	case perm.AccessModeWrite:
	scopeMatched, err = scope.HasScope(auth_model.AccessTokenScopeWritePackage)
	if err != nil {
	ctx.HTTPError(http.StatusInternalServerError, "HasScope", err.Error())
	return
	}
	}
	if !scopeMatched {
	ctx.Resp.Header().Set("WWW-Authenticate", `Basic realm="Gitea Package API"`)
	ctx.HTTPError(http.StatusUnauthorized, "reqPackageAccess", "user should have specific permission or be a site admin")
	return
	}
	// check if scope only applies to public resources
	publicOnly, err := scope.PublicOnly()
	if err != nil {
	ctx.HTTPError(http.StatusForbidden, "tokenRequiresScope", "parsing public resource scope failed: "+err.Error())
	return
	}
	if publicOnly {
	if ctx.Package != nil && ctx.Package.Owner.Visibility.IsPrivate() {
	ctx.HTTPError(http.StatusForbidden, "reqToken", "token scope is limited to public packages")
	return
	}
	}
	}

Thanks for your reply!
As you can see in my description, I've already tried that:
'''
using a PAT with all or some permissions (with packages read/write)
'''

[wxiaoguang]

Token has the permission doesn't mean the doer has the permission. Check your user, or use site admin to test.

You can also provide a reproducible setup with detailed steps, then help other people to reproduce on their side to debug.

and try to push directory to localhost docker refuses to cooporate since it requires https.

You can force docker to use insecure registry: https://www.google.com/search?client=firefox-b-d&q=docker+insecure+registry and reproduce locally by a docker-compose and then others can reproduce.

[gilgoolon]

Token has the permission doesn't mean the doer has the permission. Check your user, or use site admin to test.

I'm not sure what this means. When I look at my profile it says admin... What should I do to give my user permissions additional to my PAT? Please describe everything required to make it work.

Regarding the second part, I know about insecure registries and have already tried that, doesn't seem to help:
sudo docker info returns:

Insecure Registries:
  localhost:3000
  ::1/128
  127.0.0.0/8

yet I'm still getting this error when trying to log in:
sudo docker login localhost:3000

time="2026-03-19T14:44:09+02:00" level=info msg="Error logging in to endpoint, trying next endpoint" endpoint="{https://localhost:3000 0xc0004a05a0}" error="Get \"https://localhost:3000/v2/\": http: server gave HTTP response to HTTPS client"
Get "https://localhost:3000/v2/": http: server gave HTTP response to HTTPS client

Though this is not the actual problem, as I can communicate with the docker api behind the nginx https proxy, and by curling the API directly.

[gilgoolon]

regarding my environment, I provided all the details in the description. And as I said this is a fresh installation (of multiple versions), I don't know what else I can provide..

I don't think its a bug with the actual permissions check logic since this happens in versions from the past 3 years, probably just a misconfiguration somewhere on my side. Is there anything required to do for the registry to work that the documentation doesn't specify (create a PAT with package read/write)?

[wxiaoguang]

I will show you what is "reproducible setup with detailed steps".

## edit docker config, and restart docker daemon
  "insecure-registries": [
    "localhost:3000"
  ]

## verify docker:
$ docker info
...
 Insecure Registries:
  localhost:3000

## prepare Gitea's compose.yml
services:
  server:
    image: gitea/gitea:1.25.4
    container_name: gitea-1.25
    volumes:
      - ./gitea:/data
    ports:
      - "3000:3000"

$ docker compose up

## visit http://localhost:3000, keep everything default, install
## register user "admin" with password "12345678"
## go to user settings -> applications, add a token
## generate a new token with "package: Read and Write"

$ docker login localhost:3000
Username: admin
Password: (input the generated token)
Login Succeeded

$ docker pull nginx
$ docker tag nginx localhost:3000/admin/nginx
$ docker push  localhost:3000/admin/nginx
Using default tag: latest
The push refers to repository [localhost:3000/admin/nginx]
2bf7833cbb88: Pushed
bcc43639f11c: Pushed
6dd09f2dc2e1: Pushed
f4badedbec24: Pushed
13a86953cc5f: Pushed
74d322dac342: Pushed
39db0d317f1e: Pushed
latest: digest: sha256:be275332f8853c71c4b5dc5478840381bd43179acae1e9b1c6b93b332e12d14d size: 2292
.....

I have tested, it works.

[wxiaoguang]

I don't think its a bug with the actual permissions check logic since this happens in versions from the past 3 years, probably just a misconfiguration somewhere on my side. Is there anything required to do for the registry to work that the documentation doesn't specify (create a PAT with package read/write)?

If Gitea itself doesn't have problem, then you need to figure out the problem in your environment.

[gilgoolon]

the demonstration above works fine. Something must be wrong with the snap installation, but I'm really losing my mind about this since I'm pretty sure I did exactly the same as described above, or in the documentation.

I reinstalled my instance with the docker-compose you provided and it works even without a PAT, as advertised.

Thanks for the help, tough I'm not sure what went wrong before.