Can't push new project

Install/Maintain/Configure
1

I have had gitea running for about 7 years. I went most of that time without using it (last entry in the dashboard is some notes I made for myself as an issue 6 years ago), but just storing a few little personal projects. Recently I wanted to add another old project (that has never been in gitea) to start making some changes to it… But I keep getting errors.

When I try to push, I get a the usual git file counts and such, then a long pause, and then this:

remote:
remote: error:
remote: error: Internal Server Connection Error
remote: error:
To ``https://<hostname>/tin/project.git``
! [remote rejected] main -> main (pre-receive hook declined)
error: failed to push some refs to '``https://<hostname>/tin/project.git``'

I am not a big git or gitea user, so there’s a non-zero chance I’m doing something wrong :rofl:
But the logs don’t show anything odd. It has output with timing that matches git doing stuff, but aside from a 401 as the first entry (presumably git checking if it actually needs to send a password) everything is labelled as success.

I can pull projects including the new blank one just fine. I can create new issues on the new project. However creating a new file via the web UI “new file” button also fails to commit with the same “internal server connection error”.

2

Hi,
Can you push a file to one of your old repos?

If no then it seem slike a gitea config error, maybe
There are reported cases where pushes fail with this exact Internal Server Connection Error + pre-receive hook declined, and changing LOCAL_ROOT_URL from localhost to 127.0.0.1 fixes it. Gitea’s config is normally managed in custom/conf/app.ini

[server]
ROOT_URL = https://your-gitea-host/
LOCAL_ROOT_URL = http://127.0.0.1:3000/

if you can push then maybe
A protected-branch rule is rejecting the push, such as “require signed commits” or other protections enforced by the server hook. Gitea documents that protected branches can reject pushes containing unsigned or unverifiable commits

Check whether main is a protected branch

  1. whether signed commits are required
  2. whether your reverse proxy / HTTPS setup changed recently

If pushing to a new temporary branch works but main fails, that strongly points to branch protection rather than transport/config. If every branch fails, it points more to server config / internal hook connectivity. That inference is based on how protected-branch checks and internal pre-receive hook failures are described in Gitea docs/issues.

```

git remote -v
git push origin HEAD:refs/heads/test-push

Cheers
LP

3

Yes. It fails on old repos too…

But you did give me a clue to what might be wrong… I can’t check right now because I’m out, but after upgrading Debian 12 to 13, all my Proxmox containers lost their loopback interface (it’s there but no address). If gitea is looking for localhost or 127.0.0.1, it won’t be able to connect.

I’ll have a proper look when I get home and see if fixing the loopback interface fixes gitea.

4

Missing loopback address was the culprit… Solved.