Failed to update/create file after Gitea upgrade #3026

New Issue

GiteaMirror · 2025-11-02T04:57:52-06:00

GiteaMirror commented

2025-11-02 04:57:52 -06:00

Originally created by @DarrenRainey on GitHub (Mar 8, 2019).

Gitea version (or commit ref): 1.7.0 -> 1.7.3
Git version: 2.11.0
Operating system: Debian 9 Stretch
Database (use [x]):
- PostgreSQL
- MySQL
- MSSQL
- [ X] SQLite
Can you reproduce the bug at https://try.gitea.io:
- Yes (provide example URL)
- No
- [X ] Not relevant
Log gist:

Description

I recently upgraded my Gitea binary from 1.7.0 to the latest stable release (1.7.3) after which I notice that I can no longer edit to upload files to my existing repository with the following error (Note some information has been redacted for privacy/security reasons:

Failed to update/create file '[MY FOLDER NAME]/[FILE NAME].json' with error: git push origin master: exit status 1 - remote: ./hooks/pre-receive.d/gitea: line 2: /root/gitea: No such file or directory To /root/gitea-repositories/[MY USERNAME]/[MY PROJECT NAME].git ! [remote rejected] master -> master (pre-receive hook declined) error: failed to push some refs to '/root/gitea-repositories/[MY USERNAME]/[MY PROJECT NAME].git'

Currently if I run my original binary (1.7.0) everything seems to work as normal and I have confirmed that the files exist in the location that the error mentions so I think this maybe an issue with the newer binary or perhaps a permission related problem? all of the repository's and files were originally created or uploaded to Gitea v1.7.0 so currently this seems to be an issue with migrating to newer versions. any help would greatly be appreciated. Additionally nothing appears to be out of place in the log files regarding this issue.
...

Originally created by @DarrenRainey on GitHub (Mar 8, 2019).  - Gitea version (or commit ref): 1.7.0 -> 1.7.3 - Git version: 2.11.0 - Operating system: Debian 9 Stretch - Database (use `[x]`): - [ ] PostgreSQL - [ ] MySQL - [ ] MSSQL - [ X] SQLite - Can you reproduce the bug at https://try.gitea.io: - [ ] Yes (provide example URL) - [ ] No - [X ] Not relevant - Log gist: ## Description I recently upgraded my Gitea binary from 1.7.0 to the latest stable release (1.7.3) after which I notice that I can no longer edit to upload files to my existing repository with the following error (Note some information has been redacted for privacy/security reasons: ``` Failed to update/create file '[MY FOLDER NAME]/[FILE NAME].json' with error: git push origin master: exit status 1 - remote: ./hooks/pre-receive.d/gitea: line 2: /root/gitea: No such file or directory To /root/gitea-repositories/[MY USERNAME]/[MY PROJECT NAME].git ! [remote rejected] master -> master (pre-receive hook declined) error: failed to push some refs to '/root/gitea-repositories/[MY USERNAME]/[MY PROJECT NAME].git' ``` Currently if I run my original binary (1.7.0) everything seems to work as normal and I have confirmed that the files exist in the location that the error mentions so I think this maybe an issue with the newer binary or perhaps a permission related problem? all of the repository's and files were originally created or uploaded to Gitea v1.7.0 so currently this seems to be an issue with migrating to newer versions. any help would greatly be appreciated. Additionally nothing appears to be out of place in the log files regarding this issue. ...

GiteaMirror added the type/question label 2025-11-02 04:57:52 -06:00

GiteaMirror closed this issue

2025-11-02 04:57:52 -06:00

GiteaMirror commented

2025-11-02 04:57:53 -06:00

@DarrenRainey commented on GitHub (Mar 8, 2019):

Update: It appears after renaming my binary file from gitea-1.7.3-linux-amd64 to just gitea has solved this issue however I am going to leave this issue open as I feel that Gitea should be able to identify its own binary file such as the argv[0] function in C is used to get the current binary name. I feel this should be added as I and I assume other people may wish to have the Gitea binary called some else to make it easier to manage in my case I like to have the binary labelled by their version number.

@DarrenRainey commented on GitHub (Mar 8, 2019): Update: It appears after renaming my binary file from gitea-1.7.3-linux-amd64 to just gitea has solved this issue however I am going to leave this issue open as I feel that Gitea should be able to identify its own binary file such as the argv[0] function in C is used to get the current binary name. I feel this should be added as I and I assume other people may wish to have the Gitea binary called some else to make it easier to manage in my case I like to have the binary labelled by their version number.

GiteaMirror commented

2025-11-02 04:57:54 -06:00

@techknowlogick commented on GitHub (Mar 8, 2019):

It is git hooks that have the filename in them that are failing. We are unable to use argv[0] due to git being the executable being called. The way around this would be to override the githooks each push, however some people customize their git hooks, so this isn't a possible outcome either.

In admin dashboard there is a setting to overwrite all hooks for exactly this situation. There is also the troubleshooting section of documentation https://docs.gitea.io/en-us/install-from-binary/ which would help you in this sitiuation.

@techknowlogick commented on GitHub (Mar 8, 2019): It is git hooks that have the filename in them that are failing. We are unable to use argv[0] due to git being the executable being called. The way around this would be to override the githooks each push, however some people customize their git hooks, so this isn't a possible outcome either. In admin dashboard there is a setting to overwrite all hooks for exactly this situation. There is also the troubleshooting section of documentation https://docs.gitea.io/en-us/install-from-binary/ which would help you in this sitiuation.

GiteaMirror referenced this issue

2025-11-02 12:17:23 -06:00

[PR #3026] [MERGED] Changelog for v1.3.0 #16723

GiteaMirror referenced this issue

2025-11-02 12:18:56 -06:00

[PR #3120] [MERGED] [ci skip] Changelog for 1.3 release #16779

Sign in to join this conversation.