Join GitHub today
LFS does not transfer files. file already closed #1418
I tried to use git lfs on my gitlab but it doesn't work, even for really small files.
Here is what happens with a basic text file:
With a bigger project, and bigger commit, I have the same issue around 24MB / 324MB with extra 413 errors.
Here is a full trace of the error:
LFS was working fine up until a day or two ago. We're on an installed version of Visual Studio Team System and we're about to contact Support. The IT team says they've only restarted the TFS instance in the past day, indicating that no other maintenance has occured.
I'll post back here with a resolution (though I'm not sure whether or not it will be suitable for your Gitlab experience) when we get this figured out.
Turning on tracing for Git commands indicated that the LFS server was returning HTTP 401 (Unauthorized). From a bash terminal:
omitting lots of output
For me the solution was a little different.
When I first installed it, I had issues with an infinite redirect. The solution I found was to change the configuration file to http instead of https. This solution works for everything except lfs.
Instead, leaving the config file as https and forwarding nginx to the https port stops the infinite redirect as well as letting lfs do its thing.
I'm not sure this is a transport issue. It fails regardless of whether I use Apache's reverse proxy (intended) or the Omnibus supplied NGINX. Exact same issue.
Configurations I've tried:
Repository -> Apache (HTTPS) -> Gitlab Workhorse (HTTP) = Fails on push
Relevant Gitlab configuration:
Also tried pushing to the Omnibus NGINX ports directly excluding Apache from the loop completely, exact same issue.
@shadow7412 Can you explain a little more what you did exactly? because I think I am running into exactly the same problem but I am usure what you mean. You left apache to https? And what about the nginx setup?
@Cnidarias - I didn't use apache.
So on my server I had nginx already. I some other sites, so letting GitLab take over port 80 or 443 wasn't an option. So I mapped the docker container's port 80 to an arbitrary port number, and set nginx up to reverse proxy to this port on a specific server name.
My nginx install redirects all http traffic to the https equivalent. GitLab seemed to detect that I was connecting on 'port 80' (as that is what I was forwarding to) and would try to redirect the user to https (even though they were technically already using it) thus the infinite loop.
So instead of exposing port 80 - expose port 443, and reverse proxy to that instead.
Is that clearer?
Yes, I read that.
The servers I have running Gitlab did not have NGINX already, only the one that arrived with Gitlab's omnibus package. I had turned this off as I intended to use the already involved Apache to do the reverse proxying (by FQDN virtual host) so we could continue using SVN repositories over HTTPS+WebDAV.
The Gitlab workhorse listens fine on port 8181 for HTTP requests (but not HTTPS requests) and accessing the Gitlab web UI works fine. Just pushing a repository to it does not. I therefore tried 4 other combinations involving the omnibus provided NGINX, both directly and behind Apache, exact same push failure.
I noticed that Gitlab was using "http://" instead of "https://" in its clone URLs, which was the cause for concern regarding all the https->http redirects when pushing.
Turns out a ruddy inconsistent configuration language caused this issue for us.
For those that are still having this issue and are using Azure/TFS brand of git, there is a work around, but it requires admin access to the server (and being comfortable with regedits).
The work around is to:
Basically you have to add 2 new REG_DWORD values, EnableHttp2Tls and EnableHttp2Cleartext, to this registry key - HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\HTTP\Parameters.
You must reboot for the changes to take effect.
Force you git lfs client to use basic authenticaiton, by adding (modifying the following entries in you workspace (the .git folder) git config.
Replace collection, Project and azuredevopserver with the actually url of your server.
This was tested on git lfs 2.8.0 and 2.9.0, you mileage might vary if you are using and earlier version or newer version of git lfs.
Hope this work around helps , it isn't trivial (and might not be feasible if you don't have access to the TFS server).