Description
Gitea Version
1.14.6
Git Version
2.31.1
Operating System
NixOS
How are you running Gitea?
I run gitea as set up by the NixOS module, that means built from source and set up as a systemd service.
Database
MySQL
Can you reproduce the bug on the Gitea demo site?
No¹
Log Gist
https://gist.github.com/schmittlauch/0b6f47c899daa277b4d9df7d2861fe97
Description
I added a new 6.5GiB large file to my git repo via git lfs and tried to push the repository to my gitea remote repository, either via git push
or git lfs push
.
The upload started normally. After a while I discovered though that far more data has already been uploaded than the file size is supposed to be:
$ git push mygit mainline
loading LFS objects: 0% (0/1), 9.2 GB | 5.0 MB/s
The point of time where the upload size exceeded the actual file size is around the time when the Error: unexpected EOF
message has been logged in the gitea log.
The error happened reproducibly at several attempts, I always had to cancel the upload process manually.
The same repo – including the LFS files – has successfully been pushed to a GitLab server.
¹Due to the large file size, I did not attempt to reproduce this issue on try.gitea.io.
Activity
schmittlauch commentedon Oct 15, 2021
This issue has previously been described in the forum, without finding a proper solution: https://discourse.gitea.io/t/solved-git-lfs-upload-repeats-infinitely/635/3
I personally have tried the config changes suggested there, these do not help, and I also fail to see how each of these config params could be connected to this issue.
lunny commentedon Oct 15, 2021
I have tested locally with 5636204 and cannot reproduce it.
lunny commentedon Oct 15, 2021
What's your LFS storage configuration?
schmittlauch commentedon Oct 15, 2021
The configuration is nothing unusual. Excerpt:
schmittlauch commentedon Oct 15, 2021
It might be worth a note that the gitea instance runs behind an http2-enabled nginx reverse proxy.
client_max_body_size
is set to0
, that shouldn't be an issue.schmittlauch commentedon Oct 16, 2021
And yes, I have discovered that I just published the LFS JWT, it is changed now /0\
simonwu-os commentedon May 16, 2022
I encouter this problem today.
And at last I fixed this problem by changing nginx config to enlarge keepalive timeout.
keepalive_timeout = 100;
send_timeout 100;
theobjectivedad commentedon Oct 15, 2022
I am experiencing a similar issue, again from behind a nginx proxy running in k8s. I see messages similar to these repeating in the gitea logs during upload:
The message in Gitea obviously looks like it is a bad nginx configuration but for the life of me I cannot replicate outside of Gitea. When I upload the same files through the nginx proxy via the aws CLI everything works perfectly:
Update:
As mentioned at the end of the previously shared discord URL, adding this to my client
.git/config
worked for me: ... SOLVED!normantaipei commentedon Mar 25, 2024
I fix it by changeing the ROOT_URL , SSH_DOMAIN, DOMAIN to my local ip in app.ini file.

stevapple commentedon Mar 25, 2024
For me, the ultimate solution is to increase
lfs.activitytimeout
on client side.It turns out that all other configurations from @theobjectivedad’s snippet may not be required.
CHN-beta commentedon May 22, 2024
I encountered the same issue when uploading an LFS object with size about 25 GB.
I use btrfs, and use beesd to dedup in the background.
I solved the issue by temporarily stopping beesd.
QrackEE commentedon Sep 30, 2024
Thanks @stevapple , that fixed the problem for me! Do we agree here that the problem is more with Git not producing a timeout error correctly (and continuous sending of 'some' data)?
stevapple commentedon Sep 30, 2024
It‘s more of a problem of Gitea’s LFS implementation. Gitea collects the whole LFS object and then uploads it to S3. It should chunk the object and upload simultaneously instead.
1 remaining item