github-starred/gitea
2
0
Fork 0
mirror of https://github.com/go-gitea/gitea.git synced 2026-07-16 13:20:06 -05:00
Code Issues 2.6k Packages Projects Releases 100 Wiki Activity

Cannot clone LFS repo #2884

New Issue
Closed
opened 2025-11-02 04:52:34 -06:00 by GiteaMirror · 3 comments
GiteaMirror commented 2025-11-02 04:52:34 -06:00
Owner
Copy Link

Originally created by @rainwf2 on GitHub (Feb 9, 2019).

  • Gitea version (or commit ref): 1.7.1
  • Git version: 2.20.1 windows
  • Operating system: Windows Server 2012-R2, client Windows 10
  • Database (use [x]):
    • PostgreSQL
    • MySQL
    • MSSQL
    • [ X] SQLite
  • Can you reproduce the bug at https://try.gitea.io:
    • Yes (provide example URL)
    • No
    • [ X] Not relevant
  • Log gist:

Description

I am struggling to get Gitea with LFS working in our environment. I have a Windows Server 2012-R2 server "snttnsrtl01" and a Windows 10 client. Both have the same version of Git and Git LFS installed. I connect the client to the server over our corporate VPN. I login to the server with Remote Desktop and open snttnsrtl01:3000 with Chrome. I login as the Gitea admin and create an organization called "MCD-CIM" and a team called "test". I create 2 users "fraines" and "rainwf" and add them to the team. I create a bare repository "test-lfs2" under the MCD-CIM organization and make it available to the "test" team.

First question: is any further initialization of the repository required at this point?

While still logged into the server, I then clone the test-lfs2 repository to a folder on the server. I add a .gitattributes and a file called client1.txt containing the word "test". I commit and do a git push origin master. It prompts me for a username and password. I supply the information for the fraines user account. The push completes and when I refresh the dashboard on the Gitea page, both files appear.

The .gitattributes file is as follows:

*.txt filter=lfs diff=lfs merge=lfs -text lockable

I then go to the client and remove all Windows Credentials that are associated with previous trials. I then execute the following in a bash window. I am using http, because I am on a private network.

git clone http://snttnsrtl01:3000/MCD-CIM/test-lfs2.git

Here are the results:

Sat, Feb 9, 2019 7:31:31 AM
remote: Enumerating objects: 22, done.
remote: Counting objects: 100% (22/22), done.
remote: Compressing objects: 100% (20/20), done.
remote: Total 22 (delta 6), reused 0 (delta 0)
Unpacking objects: 100% (22/22), done.
Downloading client1.txt (6 B)
Error downloading object: client1.txt (5891b5b): Smudge error: Error downloading client1.txt (5891b5b522d5df086d0ff0b110fbd9d21bb4fc7163af34d08286a2e846f6be03): LFS: Get 5891b5b522: dial tcp [::1]:3000: connectex: No connection could be made because the target machine actively refused it.
Errors logged to C:\MCDean-Git-Projects\test-lfs2.git\lfs\logs\20190209T073201.5402165.log
Use git lfs logs last to view the log.
error: external filter 'git-lfs filter-process' failed
fatal: client1.txt: smudge filter lfs failed
warning: Clone succeeded, but checkout failed.
You can inspect what was checked out with 'git status'
and retry the checkout with 'git checkout -f HEAD'
Sat, Feb 9, 2019 7:32:01 AM

Oddly, if I create, add, commit, and push another .txt file, it prompts me for username and password (I enter those for rainwf) and it works with no error.

I have captured the following on the server:

  • app.ini: gitea configuration for server
  • bareconfig: config for the test-lfs2 bare repo
  • cloneconfig: config for the test-lfs2 cloned repo
  • serverenv: output of git lfs env
  • logserver: gitea.log for the time period above.

I have captured the following on the client:

  • clientconfig: .git/config for the test-lfs2 repo
  • clientenv: output of git lfs env
  • clientlog: C:\MCDean-Git-Projects\test-lfs2.git\lfs\logs\20190209T073201.5402165.log

The files are in the attached "lfs-clone-issue.zip".
Hopefully, you can tell me what I have done wrong. Thanks in advance for your help.

--

lfs-clone-issue.zip

--

Originally created by @rainwf2 on GitHub (Feb 9, 2019). - Gitea version (or commit ref): 1.7.1 - Git version: 2.20.1 windows - Operating system: Windows Server 2012-R2, client Windows 10 - Database (use `[x]`): - [ ] PostgreSQL - [ ] MySQL - [ ] MSSQL - [ X] SQLite - Can you reproduce the bug at https://try.gitea.io: - [ ] Yes (provide example URL) - [ ] No - [ X] Not relevant - Log gist: ## Description I am struggling to get Gitea with LFS working in our environment. I have a Windows Server 2012-R2 server "snttnsrtl01" and a Windows 10 client. Both have the same version of Git and Git LFS installed. I connect the client to the server over our corporate VPN. I login to the server with Remote Desktop and open snttnsrtl01:3000 with Chrome. I login as the Gitea admin and create an organization called "MCD-CIM" and a team called "test". I create 2 users "fraines" and "rainwf" and add them to the team. I create a bare repository "test-lfs2" under the MCD-CIM organization and make it available to the "test" team. First question: is any further initialization of the repository required at this point? While still logged into the server, I then clone the test-lfs2 repository to a folder on the server. I add a .gitattributes and a file called client1.txt containing the word "test". I commit and do a git push origin master. It prompts me for a username and password. I supply the information for the fraines user account. The push completes and when I refresh the dashboard on the Gitea page, both files appear. The .gitattributes file is as follows: ``` *.txt filter=lfs diff=lfs merge=lfs -text lockable ``` I then go to the client and remove all Windows Credentials that are associated with previous trials. I then execute the following in a bash window. I am using http, because I am on a private network. ``` git clone http://snttnsrtl01:3000/MCD-CIM/test-lfs2.git ``` Here are the results: > Sat, Feb 9, 2019 7:31:31 AM > remote: Enumerating objects: 22, done. > remote: Counting objects: 100% (22/22), done. > remote: Compressing objects: 100% (20/20), done. > remote: Total 22 (delta 6), reused 0 (delta 0) > Unpacking objects: 100% (22/22), done. > Downloading client1.txt (6 B) > Error downloading object: client1.txt (5891b5b): Smudge error: Error downloading client1.txt (5891b5b522d5df086d0ff0b110fbd9d21bb4fc7163af34d08286a2e846f6be03): LFS: Get http://localhost:3000/MCD-CIM/test-lfs2.git/info/lfs/objects/5891b5b522d5df086d0ff0b110fbd9d21bb4fc7163af34d08286a2e846f6be03: dial tcp [::1]:3000: connectex: No connection could be made because the target machine actively refused it. > Errors logged to C:\MCDean-Git-Projects\test-lfs2\.git\lfs\logs\20190209T073201.5402165.log > Use `git lfs logs last` to view the log. > error: external filter 'git-lfs filter-process' failed > fatal: client1.txt: smudge filter lfs failed > warning: Clone succeeded, but checkout failed. > You can inspect what was checked out with 'git status' > and retry the checkout with 'git checkout -f HEAD' > Sat, Feb 9, 2019 7:32:01 AM Oddly, if I create, add, commit, and push another .txt file, it prompts me for username and password (I enter those for rainwf) and it works with no error. I have captured the following on the server: * app.ini: gitea configuration for server * bareconfig: config for the test-lfs2 bare repo * cloneconfig: config for the test-lfs2 cloned repo * serverenv: output of git lfs env * logserver: gitea.log for the time period above. I have captured the following on the client: * clientconfig: .git/config for the test-lfs2 repo * clientenv: output of git lfs env * clientlog: C:\MCDean-Git-Projects\test-lfs2\.git\lfs\logs\20190209T073201.5402165.log The files are in the attached "lfs-clone-issue.zip". Hopefully, you can tell me what I have done wrong. Thanks in advance for your help. -- [lfs-clone-issue.zip](https://github.com/go-gitea/gitea/files/2848041/lfs-clone-issue.zip) --
GiteaMirror added the type/questionissue/not-a-bug labels 2025-11-02 04:52:35 -06:00
GiteaMirror commented 2025-11-02 04:52:35 -06:00
Author
Owner
Copy Link

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

The date clone date commands were separate commands at the bash prompt. Somehow, they were copied to the same line in the problem description.

@rainwf2 commented on GitHub (Feb 9, 2019): The date clone date commands were separate commands at the bash prompt. Somehow, they were copied to the same line in the problem description.
GiteaMirror commented 2025-11-02 04:52:35 -06:00
Author
Owner
Copy Link

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

I'm sorry you're having difficulty.

The original issue report was essentially unreadable due to formatting issues - I've tried to reformat it to make it a bit clearer.

If you look closely at the response from the git clone command you'll see it tells you what the problem is:

Error downloading object: client1.txt (5891b5b): Smudge error: Error downloading client1.txt (5891b5b522d5df086d0ff0b110fbd9d21bb4fc7163af34d08286a2e846f6be03): LFS: Get 5891b5b522: dial tcp [::1]:3000: connectex: No connection could be made because the target machine actively refused it.

Looking closely at this line you'll see that your client is trying to get its LFS objects from:

http://localhost:3000/MCD-CIM/test-lfs2.git/info/lfs/objects/5891b5b522d5df086d0ff0b110fbd9d21bb4fc7163af34d08286a2e846f6be03

Instead of presumably your intended domain of snttnsrtl01 and if you look closely at the provided app.ini you will see that you are telling gitea that it should tell users to look for it on localhost:

[server]
SSH_DOMAIN       = localhost # <--
DOMAIN           = localhost # <--
HTTP_PORT        = 3000
ROOT_URL         = http://localhost:3000/ # <--
DISABLE_SSH      = true
LFS_START_SERVER = true
LFS_CONTENT_PATH = D:/gitea/data/

You cannot have Gitea run on localhost and some other domain at the same time - unless you have some rewriting proxy. You probably want:

[server]
SSH_DOMAIN       = snttnsrtl01 # <--
DOMAIN           = snttnsrtl01 # <--
HTTP_PORT        = 3000
ROOT_URL         = http://snttnsrtl01:3000/ # <--
DISABLE_SSH      = true
LFS_START_SERVER = true
LFS_CONTENT_PATH = D:/gitea/data/

PS you've posted your app.ini with its secrets in entirety, you should not use those secrets again.

@zeripath commented on GitHub (Feb 9, 2019): I'm sorry you're having difficulty. The original issue report was essentially unreadable due to formatting issues - I've tried to reformat it to make it a bit clearer. If you look closely at the response from the `git clone` command you'll see it tells you what the problem is: > Error downloading object: client1.txt (5891b5b): Smudge error: Error downloading client1.txt (5891b5b522d5df086d0ff0b110fbd9d21bb4fc7163af34d08286a2e846f6be03): LFS: Get http://localhost:3000/MCD-CIM/test-lfs2.git/info/lfs/objects/5891b5b522d5df086d0ff0b110fbd9d21bb4fc7163af34d08286a2e846f6be03: dial tcp [::1]:3000: connectex: No connection could be made because the target machine actively refused it. Looking closely at this line you'll see that your client is trying to get its LFS objects from: > http://**localhost**:3000/MCD-CIM/test-lfs2.git/info/lfs/objects/5891b5b522d5df086d0ff0b110fbd9d21bb4fc7163af34d08286a2e846f6be03 Instead of presumably your intended domain of `snttnsrtl01` and if you look closely at the provided `app.ini` you will see that you are telling gitea that it should tell users to look for it on `localhost`: ```ini [server] SSH_DOMAIN = localhost # <-- DOMAIN = localhost # <-- HTTP_PORT = 3000 ROOT_URL = http://localhost:3000/ # <-- DISABLE_SSH = true LFS_START_SERVER = true LFS_CONTENT_PATH = D:/gitea/data/ ``` You cannot have Gitea run on localhost and some other domain at the same time - unless you have some rewriting proxy. You probably want: ```ini [server] SSH_DOMAIN = snttnsrtl01 # <-- DOMAIN = snttnsrtl01 # <-- HTTP_PORT = 3000 ROOT_URL = http://snttnsrtl01:3000/ # <-- DISABLE_SSH = true LFS_START_SERVER = true LFS_CONTENT_PATH = D:/gitea/data/ ``` PS you've posted your `app.ini` with its secrets in entirety, you should not use those secrets again.
GiteaMirror commented 2025-11-02 04:52:36 -06:00
Author
Owner
Copy Link

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

Thank you so much. This fixed my problem. On a Saturday no less!
It is just a test installation.
It was not clear to me that the URLs in app.ini were a reference for the instance of Gitea running on the server or for the client connecting to the server.

@rainwf2 commented on GitHub (Feb 9, 2019): Thank you so much. This fixed my problem. On a Saturday no less! It is just a test installation. It was not clear to me that the URLs in app.ini were a reference for the instance of Gitea running on the server or for the client connecting to the server.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
$20
$250
$50
$500
backport/done
💎 Bounty
docs-update-needed
good first issue
hacktoberfest
issue/bounty
issue/confirmed
issue/critical
issue/duplicate
issue/needs-feedback
issue/not-a-bug
issue/regression
issue/stale
issue/workaround
lgtm/need 2
modifies/api
modifies/translation
outdated/backport/v1.18
outdated/theme/markdown
outdated/theme/timetracker
performance/bigrepo
performance/cpu
performance/memory
performance/speed
pr/breaking
proposal/accepted
proposal/rejected
pr/wip
pull-request
Mirrored from GitHub Pull Request
 reviewed/wontfix
💰 Rewarded
skip-changelog
status/blocked
topic/accessibility
topic/api
topic/authentication
topic/build
topic/code-linting
topic/commit-signing
topic/content-rendering
topic/deployment
topic/distribution
topic/federation
topic/gitea-actions
topic/issues
topic/lfs
topic/mobile
topic/moderation
topic/packages
topic/pr
topic/projects
topic/repo
topic/repo-migration
topic/security
topic/theme
topic/ui
topic/ui-interaction
topic/ux
topic/webhooks
topic/wiki
type/bug
type/deprecation
type/docs
type/enhancement
type/feature
type/miscellaneous
type/proposal
type/question
type/refactoring
type/summary
type/testing
type/upstream
No Label issue/not-a-bug type/question
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
GiteaMirror ninjasurge
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/gitea#2884
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?