LFS does not transfer files. file already closed #1418
Comments
|
Did you ever find a resolution to this? We've started experiencing the same problem. |
|
I'm sorry to hear that, I still have this 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 |
|
“Visual Studio Team System” — we use that as well. Was there any fix? |
|
I'm still having this error. Is there a fix? |
|
We have this problem too. Anyone? |
|
Yes same here, anyone an idea? |
|
I faced the same problem and solved it by executing git lfs fetch |
|
Fixing the domain url for lfs did the job for me |
|
We worked around it by fixing the URLs we use to communicate with the TFS. Our TFS server is configured to return URLs without the domain suffix, so removing the domain suffix from all the URLs in the git configuration fixes the problem. |
|
I'm stuck here in 2019. Nothing written above fixed my issue. Mine never explicitly fails though. It just keeps running |
|
@Zanndorin even with GIT_TRACE=1 ? Same, I still have my original issue |
|
@AlexandreRio Well Git_trace only shows us that we have the file already closed issue. so yeah, even "with GIT_TRACE=1". |
@andriy-guzenko fixing it from what, to what? |
|
@shadow7412 Mark Kharitonov explained this better above. Removing domain suffix from url fixed the issue. |
|
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: Apache VHOST: With the
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? |
|
@shadow7412 yes that was very clear and I was able to get it to work now as well thank you very much |
|
I guess Gitlab LFS doesn't work at all over HTTPS anymore then? |
|
@Adambean no, it works... |
|
Hm ok, what would be causing the "file already closed" issue? I've tried a lot of combinations of both with and without the supplied NGINX. |
|
Did you read my comment above? It solved the issue for me... |
|
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. |
|
Resolved it. 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. Step 2: Step 3: 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). |
|
I ran into the whole "file is already closed" bit. I had migrated my gitea instance to be behind a reverse proxy that was terminating TLS. I needed to update the |
|
Try to just upgrade your On Ubuntu 20 it's too old by default and must be upgraded by curl -s https://packagecloud.io/install/repositories/github/git-lfs/script.deb.sh | sudo bash
sudo apt install git-lfs |
I tried to use git lfs on my gitlab but it doesn't work, even for really small files.
LFS is enabled both in gitlab settings and project settings.
I'm using
git-lfs/2.3.4andgit version 2.15.0withgitlab 10.1.4.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.
If I look in the data folder of the container the lfs directory is empty.
The web interface of gitlab is behind a nginx proxy but the ssh port is directly binded to my host machine.
Here is a full trace of the error:
The text was updated successfully, but these errors were encountered: