Git LFS push fails #2842

@rainwf2 commented on GitHub (Jan 31, 2019):

I assume I can just update gitea.exe leave everything else in place. Or do I need to start from scratch?

@rainwf2 commented on GitHub (Jan 31, 2019): I assume I can just update gitea.exe leave everything else in place. Or do I need to start from scratch?

GiteaMirror commented

@zeripath commented on GitHub (Jan 31, 2019):

I think so.

@zeripath commented on GitHub (Jan 31, 2019): I think so.

GiteaMirror commented

@rainwf2 commented on GitHub (Feb 1, 2019):

Fundamental question: Must gitea admin and collaborator user names exist as valid domain names on the server? Our organisation requires user names to have a space between first and last name: e.g. "John Doe". Gitea will not allow spaces in the user name, so I have created a collaborator name of "jdoe". Is this the root of my problem. If so, we will not be able to use gitea.

@rainwf2 commented on GitHub (Feb 1, 2019): Fundamental question: Must gitea admin and collaborator user names exist as valid domain names on the server? Our organisation requires user names to have a space between first and last name: e.g. "John Doe". Gitea will not allow spaces in the user name, so I have created a collaborator name of "jdoe". Is this the root of my problem. If so, we will not be able to use gitea.

GiteaMirror commented

@rainwf2 commented on GitHub (Feb 1, 2019):

After reading gitea #1641, let me be specific: our organisation requires space in "username".

@rainwf2 commented on GitHub (Feb 1, 2019): After reading gitea #1641, let me be specific: our organisation requires space in "username".

GiteaMirror commented

@zeripath commented on GitHub (Feb 1, 2019):

No I don't think so.

Ok, I think we need a bit more information about how you're logging in to Gitea and how you've set it up.

By: "clone a localhost" you mean, you are on the machine that runs Gitea and you do: git clone http://localhost/user/repo.git and it gets the LFS objects correctly?

Where does the client then collect the LFS objects from? How do you login? Is this local db login or LDAP/domain login?

Then when you attempt to clone from network, where exactly are you trying to clone from? You have to change the Gitea rooturl to match this url. Giteas LFS server can only report one address so you cannot have LFS work by reporting localhost for localhost queries and some other address for non-localhost queries. (This could be fixed but getting the configuration right might be very hard.)

Assuming you changed the config, how are you logging in? Local or LDAP/AD? Which username?

BTW try.gitea.io doesn't have LFS setup so isn't a good test case.

@zeripath commented on GitHub (Feb 1, 2019): No I don't think so. Ok, I think we need a bit more information about how you're logging in to Gitea and how you've set it up. By: "clone a localhost" you mean, you are on the machine that runs Gitea and you do: `git clone http://localhost/user/repo.git` and it gets the LFS objects correctly? Where does the client then collect the LFS objects from? How do you login? Is this local db login or LDAP/domain login? Then when you attempt to clone from network, where exactly are you trying to clone from? You have to change the Gitea rooturl to match this url. Giteas LFS server can only report one address so you cannot have LFS work by reporting localhost for localhost queries and some other address for non-localhost queries. (This could be fixed but getting the configuration right might be very hard.) Assuming you changed the config, how are you logging in? Local or LDAP/AD? Which username? BTW try.gitea.io doesn't have LFS setup so isn't a good test case.

GiteaMirror commented

@rainwf2 commented on GitHub (Feb 1, 2019):

First question = yes
Second question = localhost – same URL
Third question = login with collaborator username and password – “jdoe”
Fourth question = local db login
Fifth question = tried both http://:3000/gitea-admin/lfs-test.githttp://%3cserver%3e:3000/gitea-admin/lfs-test.git and https://:3000/gitea-admin/lfs-test.githttps://%3cserver%3e:3000/gitea-admin/lfs-test.git

gitea-admin is admin I set up when installing Gitea
gitea-admin created the test-lfs repo

LFS URL is same. I am not specifically referencing the LFS URL in this test

Did not change the config from the values entered during initial run of Gitea.

Sixth question = logging in as “jdoe” NOT as “John Doe” which is the domain username

Seventh question = assume local, since I did not set up LDAP/AD

Good to know about try.gitea.io – suggestion some notation on site to notify users or perhaps I missed it.

@rainwf2 commented on GitHub (Feb 1, 2019): First question = yes Second question = localhost – same URL Third question = login with collaborator username and password – “jdoe” <password> Fourth question = local db login Fifth question = tried both http://<server>:3000/gitea-admin/lfs-test.git<http://%3cserver%3e:3000/gitea-admin/lfs-test.git> and https://<server>:3000/gitea-admin/lfs-test.git<https://%3cserver%3e:3000/gitea-admin/lfs-test.git> gitea-admin is admin I set up when installing Gitea gitea-admin created the test-lfs repo LFS URL is same. I am not specifically referencing the LFS URL in this test Did not change the config from the values entered during initial run of Gitea. Sixth question = logging in as “jdoe” <password> NOT as “John Doe” which is the domain username Seventh question = assume local, since I did not set up LDAP/AD Good to know about try.gitea.io – suggestion some notation on site to notify users or perhaps I missed it.

GiteaMirror commented

@zeripath commented on GitHub (Feb 1, 2019):

Ugh the formatted of that reply was totally messed up. You might wanna pop on to GitHub to fix it up. -- weirdly this only seems to affect the mobile phone view...

I think you're saying, that when you moved from testing on the localhost you didn't change the configuration of Gitea to re set its root url from localhost. That won't work. You have to change the Gitea root url and restart Gitea.

You will also have to reclone the git repository from this Gitea as getting LFS to change its URL can be very difficult indeed. Check your .git/config for the cloned repo to ensure that LFS is pointing to the correct place.

If everything is definitely pointing to the correct place then we need to think a bit more.

@zeripath commented on GitHub (Feb 1, 2019): Ugh the formatted of that reply was totally messed up. You might wanna pop on to GitHub to fix it up. -- weirdly this only seems to affect the mobile phone view... I think you're saying, that when you moved from testing on the localhost you didn't change the configuration of Gitea to re set its root url from localhost. That won't work. You have to change the Gitea root url and restart Gitea. You will also have to reclone the git repository from this Gitea as getting LFS to change its URL can be very difficult indeed. Check your .git/config for the cloned repo to ensure that LFS is pointing to the correct place. If everything is definitely pointing to the correct place then we need to think a bit more.

GiteaMirror commented

@rainwf2 commented on GitHub (Feb 1, 2019):

Format looks fine on https://github.com/go-gitea/gitea/issues/5920

I have Gitea installed on 2 computers, my laptop which I reference as localhost, and a server which I reference as . Each is set up independently with v1.7.1. One difference is that the server is on our company domain and I access it with VPN.

In both cases I did a fresh install of 1.7.1. When I access gitea on my laptop, I use http://localhost:3000/gitea-admin/test-lfs.git

When I access gitea on the server, I use https://:3000/gitea-admin/test-lfs.git, although I have also tried http://:3000/gitea-admin/test-lfs.git

In both cases, I use "jdoe" . My domain name is "John Doe" however.

It works when I reference gitea on my laptop but not on the server.

I hope this is more clear.

@rainwf2 commented on GitHub (Feb 1, 2019): Format looks fine on https://github.com/go-gitea/gitea/issues/5920 I have Gitea installed on 2 computers, my laptop which I reference as localhost, and a server which I reference as <server>. Each is set up independently with v1.7.1. One difference is that the server is on our company domain and I access it with VPN. In both cases I did a fresh install of 1.7.1. When I access gitea on my laptop, I use http://localhost:3000/gitea-admin/test-lfs.git When I access gitea on the server, I use https://<server>:3000/gitea-admin/test-lfs.git, although I have also tried http://<server>:3000/gitea-admin/test-lfs.git In both cases, I use "jdoe" <password>. My domain name is "John Doe" however. It works when I reference gitea on my laptop but not on the server. I hope this is more clear.

GiteaMirror commented

@zeripath commented on GitHub (Feb 1, 2019):

Ok, are the two clones are completely separate?

Is the LFS URL in .git/config pointing to the correct place?

When you created the repository on the server, how did you create this - Did you push it afresh or just copy the data over in the filesystem? When you pushed it are you certain you also pushed over the LFS objects? If the clone had an LFS config already it can be very difficult to tell it to use the new one. If you just copied over the filesystem did you also copy the database? (When you create LFS objects they're given an sha256sum that has to be registered with the repository id in the database. Even if the file is in the LFS filesystem the database needs to know that they're in that repo)

Check that the files are in the LFS filesystem on the repository. Try creating a completely new test LFS repository and pushing it to the server.

@zeripath commented on GitHub (Feb 1, 2019): Ok, are the two clones are completely separate? Is the LFS URL in .git/config pointing to the correct place? When you created the repository on the server, how did you create this - Did you push it afresh or just copy the data over in the filesystem? When you pushed it are you certain you also pushed over the LFS objects? If the clone had an LFS config already it can be very difficult to tell it to use the new one. If you just copied over the filesystem did you also copy the database? (When you create LFS objects they're given an sha256sum that has to be registered with the repository id in the database. Even if the file is in the LFS filesystem the database needs to know that they're in that repo) Check that the files are in the LFS filesystem on the repository. Try creating a completely new test LFS repository and pushing it to the server.

GiteaMirror commented

@rainwf2 commented on GitHub (Feb 1, 2019):

Yes.
laptop [lfs "http://localhost:3000/gitea-admin/test-lfs.git/info/lfs"]
server [lfs "https://:3000/gitea-admin/test-lfs.git/info/lfs"]
On laptop, used localhost:3000 logged in as git-admin, created lfs-test.git fresh.
Logged into server with domain credentials, used localhost:3000 logged in as git-admin, created lfs-test.git fresh.
Separate fresh repos on laptop and server.
Separate fresh clone on laptop from laptop gitea (works)
Separate fresh clone on laptop, connected to domain, from server (doesn't work)
Performed steps in gitea #3101 to test for repo on laptop and then server.
Removed clone on laptop before testing with server.
In both cases only trying to push .gitattributes and foobar.txt. The repo is empty beforehand, just like gitea #3101

@rainwf2 commented on GitHub (Feb 1, 2019): Yes. laptop [lfs "http://localhost:3000/gitea-admin/test-lfs.git/info/lfs"] server [lfs "https://<server>:3000/gitea-admin/test-lfs.git/info/lfs"] On laptop, used localhost:3000 logged in as git-admin, created lfs-test.git fresh. Logged into server with domain credentials, used localhost:3000 logged in as git-admin, created lfs-test.git fresh. Separate fresh repos on laptop and server. Separate fresh clone on laptop from laptop gitea (works) Separate fresh clone on laptop, connected to domain, from server (doesn't work) Performed steps in gitea #3101 to test for repo on laptop and then server. Removed clone on laptop before testing with server. In both cases only trying to push .gitattributes and foobar.txt. The repo is empty beforehand, just like gitea #3101

GiteaMirror commented

https://github.com/go-gitea/gitea/issues/5888#issuecomment-459950629

@zeripath commented on GitHub (Feb 2, 2019):

In case it's not clear I'm very confused as to why you're having so much difficulty.

Logged into server with domain credentials, used localhost:3000 logged in as git-admin, created lfs-test.git fresh.

Sorry did you just mean what you said:

Log on to server presumably using Terminal Services.
From this terminal services session, on the server, use its local web browser to log-in as git-admin into http://localhost:3000/ ie. on the server, and create a new repository

You shouldn't be able to do that. Gitea can only work with one external address - everything has to be that. What does your app.ini look like? Here's what mine looks like on my external server that is proxy passed through nginx.

[server]
ROOT_URL         = https://www.domain.com/git/
SSH_DOMAIN       = www.domain.com
DOMAIN           = www.domain.com
HTTP_PORT        = 3000
DISABLE_SSH      = false
SSH_PORT         = 22
...

Note that although the server is actually listening on port 3000 it's being proxied through to port 80 by nginx and therefore my ROOT_URL doesn't have the 3000. Similarly I proxy through to a /git suburl hence the /git.

I see you've written that the server url is "http://:3000" - I've been presuming that you're censoring the host address - but if that's your address that's not going to work. Gitea needs a fixed domain.

Now if your server is sitting behind IIS take a look at:

@zeripath commented on GitHub (Feb 2, 2019): In case it's not clear I'm very confused as to why you're having so much difficulty. > Logged into server with domain credentials, used localhost:3000 logged in as git-admin, created lfs-test.git fresh. Sorry did you just mean what you said: * Log on to server presumably using Terminal Services. * From this terminal services session, on the server, use its local web browser to log-in as git-admin into http://localhost:3000/ ie. on the server, and create a new repository You shouldn't be able to do that. Gitea can only work with one external address - everything has to be that. What does your app.ini look like? Here's what mine looks like on my external server that is proxy passed through nginx. ``` [server] ROOT_URL = https://www.domain.com/git/ SSH_DOMAIN = www.domain.com DOMAIN = www.domain.com HTTP_PORT = 3000 DISABLE_SSH = false SSH_PORT = 22 ... ``` Note that although the server is actually listening on port 3000 it's being proxied through to port 80 by nginx and therefore my ROOT_URL doesn't have the 3000. Similarly I proxy through to a `/git` suburl hence the `/git`. I see you've written that the server url is "http://:3000" - I've been presuming that you're censoring the host address - but if that's your address that's not going to work. Gitea needs a fixed domain. Now if your server is sitting behind IIS take a look at: https://github.com/go-gitea/gitea/issues/5888#issuecomment-459950629

GiteaMirror commented

@rainwf2 commented on GitHub (Feb 4, 2019):

It now works.
I found my first error installing Gitea on the server. For testing, I am using SQLite3. During initalization via the gitea web interface, it asks for the path to the database, with the default "data/gitea.db" and the note "File path for the SQLite3 database. Enter an absolute path if you run Gitea as a service.", which I am. This is different from the LFS and repository location defaults which are of the form "C:\xxx\xxx" My use of Git bash caused me to provide the path "/d /gitea/data/gitea.db". While using Window Explorer, I discovered that Gitea had created a folder "d/gitea/data" containing gitea.db. I have now corrected the path to "D:/gitea/data/gitea.db".

My second problem was that I did not clear the SSH port number during initialization to disable SSH.

Also, after thinking the process through, I realized that my server URL should be http rather than https, since I have done nothing to set up SSH on the server.

I am working within a domain with local access to the server. The server is not exposed to the outside world. My reading is that http should be an acceptable way to access gitea on the server. Please correct me if I am wrong.

@rainwf2 commented on GitHub (Feb 4, 2019): It now works. I found my first error installing Gitea on the server. For testing, I am using SQLite3. During initalization via the gitea web interface, it asks for the path to the database, with the default "data/gitea.db" and the note "File path for the SQLite3 database. Enter an absolute path if you run Gitea as a service.", which I am. This is different from the LFS and repository location defaults which are of the form "C:\xxx\xxx" My use of Git bash caused me to provide the path "/d /gitea/data/gitea.db". While using Window Explorer, I discovered that Gitea had created a folder "d/gitea/data" containing gitea.db. I have now corrected the path to "D:/gitea/data/gitea.db". My second problem was that I did not clear the SSH port number during initialization to disable SSH. Also, after thinking the process through, I realized that my server URL should be http rather than https, since I have done nothing to set up SSH on the server. I am working within a domain with local access to the server. The server is not exposed to the outside world. My reading is that http should be an acceptable way to access gitea on the server. Please correct me if I am wrong. --

GiteaMirror commented