Critical startup failure on 'latest' Docker image: su-exec: Permission denied

[magowiz]

Description

Hello Gitea Team,

I am experiencing a critical startup failure when using the gitea/gitea:latest Docker image. The container enters a crash loop.

Environment Details:
All environment details (Host OS, Docker Version, docker-compose.yml) are included in the attached log file.

Problem Description:
When trying to start a Gitea container using image: gitea/gitea:latest with the provided docker-compose.yml, the container fails
to start and logs show a repeated su-exec: /usr/local/bin/gitea: Permission denied error.

Diagnostics and Findings:

• We have confirmed that this is not a standard file permission issue, as permissions inside the container appear to be correct
  (-rwxr-xr-x).
• The key finding is that the issue does not occur when using a specific version tag, for example gitea/gitea:1.21.11. The
  container with the versioned tag starts without the su-exec permission error.
• This strongly suggests the issue is with the build of the :latest tag itself.
• Side note: Running the broken :latest image, even briefly, updated the database schema, making it incompatible with older Gitea
  versions.

Please find all relevant logs, configuration, and system info in the attached file.

Thank you.

gitea_logs.txt

Gitea Version

1.24.5

Can you reproduce the bug on the Gitea demo site?

No

Log Gist

No response

Screenshots

No response

Git Version

No response

Operating System

Raspbian

How are you running Gitea?

I'm running gitea in a docker compose.

Database

Sqlite3

[wxiaoguang]

It doesn't seem to be a Gitea's problem.

Maybe you made something wrong in your configuration or there are some bugs in your container volumes (drivers)

services:
  server:
    image: gitea/gitea:latest
    container_name: gitea
    volumes:
      - ./gitea:/data
    ports:
      - "3002:3000"
      - "3022:22"

[magowiz]

Hello,
I've performed further testing with the gitea/gitea:latest Docker image, using docker compose service definition provided, unfortunately, the issue persists. The container still fails to start with the su-exec: /usr/local/bin/gitea: Permission denied error, leading to a continuous crash loop.
Furthermore, when attempting to revert to gitea/gitea:1.21.11 works but there is: "Your database (migration version: 321) is for a newer Gitea, you can not use the newer database for this old Gitea release (280)."
Thank you for your attention to this matter.

[wxiaoguang]

You can try it in another environment. I have tried that simple docker-compose file, it doesn't fail. And plenty of users also use latest image, there is nothing wrong in it.

See my comment:

or there are some bugs in your container volumes (drivers)

(for example: Git push fails with "Permission denied" on tmp_objdir in rootless Gitea on Kubernetes with old Longhorn CSI driver #35032 )

[magowiz]

I tried successfully using a couple of version earlier, with same example, same environment, for me downgrading to 1.24.3 gave me back a working gitea, now I have other issues involving mine data, but it is another problem.

I used exactly your compose service, it didn't work until I pinned gitea 1.24.3, I don't know, maybe recent builds has some issues with arm64 ?

[wxiaoguang]

I used exactly your compose service, it didn't work until I pinned gitea 1.24.3, I don't know, maybe recent builds has some issues with arm64 ?

Really strange, I am also testing it on arm64, docker inspect says:

                "org.opencontainers.image.created": "2025-08-13T16:00:30.404Z",
                "org.opencontainers.image.revision": "136ec9ef812a3e684c6c86f535e3db5f74654308",
                "org.opencontainers.image.version": "1.24.5"


        "ImageManifestDescriptor": {
            "mediaType": "application/vnd.oci.image.manifest.v1+json",
            "digest": "sha256:f0eb0ad9bba4f15f7a06181dd173d1d0e1948da6643b6f089df2eaa00a3fb31f",
            "size": 1624,
            "platform": {
                "architecture": "arm64",
                "os": "linux"
            }
        }

[wxiaoguang]

same environment,

Can you try another clean environment?