Git Push Fails - fatal: The remote end hung up unexpectedly
Platform Notice: Data Center Only - This article only applies to Atlassian apps on the Data Center platform.
Note that this KB was created for the Data Center version of the product. Data Center KBs for non-Data-Center-specific features may also work for Server versions of the product, however they have not been tested. Support for Server* products ended on February 15th 2024. If you are running a Server product, you can visit the Atlassian Server end of support announcement to review your migration options.
*Except Fisheye and Crucible
Problem
When users try to run "git push" the following error message is shown:
$ git push
Counting objects: 2332669, done.
Delta compression using up to 16 threads.
Compressing objects: 100% (360818/360818), done.
error: RPC failed; result=22, HTTP code = 411
fatal: The remote end hung up unexpectedly
Writing objects: 100% (2332669/2332669), 483.30 MiB | 114.26 MiB/s, done.
Total 2332669 (delta 1949888), reused 2330461 (delta 1949349)
fatal: The remote end hung up unexpectedlySymptom
Scenario | How to identify | Likely cause | Fix |
|---|---|---|---|
Pushing large files or repositories | The push fails immediately, or after several seconds when transferring data | HTTP buffer size on client is too small for the data being transferred | Increase git config |
Push fails consistently regardless of file size or connection speed | Consistent disconnection every attempt, not dependent on data size | Server-side issue: Bitbucket process crash, proxy timeout, or network configuration | Review application logs at |
Cause
The "Smart HTTP" protocol in Git uses "Transfer-Encoding: chunked" in POST requests when it contains packed objects greater than 1MB in size.
Some proxy servers, like Nginx, do not support this transfer encoding by default, and the requests will be rejected before they get to Bitbucket Server. Because of this, the Bitbucket Server logs will not show any extra information.
Another possible cause is a load balancer misconfiguration.
Workaround
When pushing a large amount of data (initial push of a big repository, change with very big file(s)) may require a higher
http.postBuffersetting on your git client (not the server). From https://www.kernel.org/pub/software/scm/git/docs/git-config.htmlhttp.postBuffer
Maximum size in bytes of the buffer used by smart HTTP transports when POSTing data to the remote system. For requests larger than this buffer size, HTTP/1.1 and Transfer-Encoding: chunked is used to avoid creating a massive pack file locally. Default is 1 MiB, which is sufficient for most requests.
Configuration on your reverse proxy. Usually ngnix the parameter
client_max_body_sizeis a blocker. The reverse proxy may also have a connection timeout that's closing the connection (e.g.TimeOutorProxyTimeoutin apache,proxy_read_timeoutin ngnix). Try bypassing the proxy by pushing directly to Bitbucket Server IP:port. If this works, it's highly likely that the proxy server is causing the early disconnect and needs to be tuned.User is using an outbound proxy on his machine that is causing the issue.
Resolution
Increase the Git buffer size to the largest individual file size of your repo:
git config --global http.postBuffer 157286400
Refer to the resolution of Git push fails - client intended to send too large chunked body for ngnix reverse proxy configuration. Increase this parameter to the largest individual file size of your repo.
Bypass the outbound proxy as explained on Can't clone or pull due to a git outbound proxy
Verification
After applying the buffer size fix on the local Git client, attempt to push again
If the push succeeds, the issue is resolved
Try pushing another branch or a different set of commits to confirm the fix is stable
If you suspect a server-side issue, ask your Bitbucket administrator to check the
$BITBUCKET_HOME/log/atlassian-bitbucket.logfor errors during the failed push
Was this helpful?