Git clone LFS fails with dial tcp <IP>:<Port>: i/o timeout
Platform notice: Server and Data Center only. This article only applies to Atlassian products on the Server and Data Center platforms.
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
Cloning (or any other LFS server interactions) via SSH will fail if the Bitbucket Server has a misconfigured URL. An error message such as the following will be presented to the client:
Post http://<BITBUCKET_SERVER_URL>/scm/myproject/myrepo.git/info/lfs/objects/batch: dial tcp XXX.XXX.XXX.XX:YY: i/o timeoutCause
The command line client is unable to connect to the Bitbucket server instance because the URL is incorrect (i.e. mismatching between the <BITBUCKET_SERVER_URL> and the "Base URL").
Resolution
This occurs only via SSH, HTTP access is unaffected. This occurs because Git LFS does not actually support SSH; it does however permit that is configured with an SSH "remote" to, via SSH, contact the Bitbucket Server instance and request the HTTP/S URL and an authorisation token. The Bitbucket Server instance will reply with a URL that is based on the configured Base URL.
To resolve this see: Specifying the base URL for Bitbucket Server.
How do SSH remotes work?
The Git LFS Batch API does not directly support SSH, instead Bitbucket Server will redirect clients to a HTTP/S URL. So how does this work?
If using an SSH remote, the client (specifically the LFS filter) will make the following request via SSH for a download request:
git-lfs-authenticate myproject/myrepo.git download
The server will then respond with a JSON document, for example:
{
"header": {
"Authorization": "JWT <...JWT token...>"
},
"href": "https://bitbucket.example.com:7990/scm/myproject/myrepo.git/info/lfs"
}
The Git LFS client will then POST a batch request via the returned URL.