github-starred/gitea
2
0
Fork 0
mirror of https://github.com/go-gitea/gitea.git synced 2026-03-11 17:46:29 -05:00
Code Issues 2.6k Packages Projects Releases 100 Wiki Activity

Can't clone repo after commiting lfs files #9864

New Issue
Closed
opened 2025-11-02 08:51:43 -06:00 by GiteaMirror · 10 comments
GiteaMirror commented 2025-11-02 08:51:43 -06:00
Owner
Copy Link

Originally created by @night-gold on GitHub (Nov 21, 2022).

Description

We are doing a test install of gitea and trying to use the gitea lfs to s3 feature. The configuration is straightforward and we did it like that:

[lfs]
#PATH = /opt/gitea/data/lfs
STORAGE_TYPE = minio
MINIO_ACCESS_KEY_ID = KEY
MINIO_SECRET_ACCESS_KEY = SECRET
MINIO_BUCKET = NAME
MINIO_LOCATION = us-east-1
MINIO_USE_SSL = true
SERVE_DIRECT = true
MINIO_ENDPOINT = s3.us-east-1.amazonaws.com

That works, I created a repo and cloned another I had at disposal with lfs config. I managed to commit and push all my lfs files and it uploaded everything on the s3. So that's great.

But now I have an issue when cloning the repo, the clone does get the git files but when trying to get the lfs files on the s3 I get this message:

Error downloading object: FILE (hash): Smudge error: Error downloading FILE (hash): LFS: Get "https://NAME.s3.dualstack.us-east-1.amazonaws.com/lfs/PATHTOFILE": dial tcp: lookup NAME.s3.dualstack.us-east-1.amazonaws.com on IP:53: dial udp IP:53: socket: too many open files
From what I get it's only trying to get one file but even that doesn't work.

Has anyone seen that before?

Gitea Version

1.17.3

Can you reproduce the bug on the Gitea demo site?

No

Log Gist

No response

Screenshots

No response

Git Version

No response

Operating System

Debian

How are you running Gitea?

Installed gitea using one of the downloads, it is for testing purpose launched manually on foreground.

Database

PostgreSQL

Originally created by @night-gold on GitHub (Nov 21, 2022). ### Description We are doing a test install of gitea and trying to use the gitea lfs to s3 feature. The configuration is straightforward and we did it like that: ``` [lfs] #PATH = /opt/gitea/data/lfs STORAGE_TYPE = minio MINIO_ACCESS_KEY_ID = KEY MINIO_SECRET_ACCESS_KEY = SECRET MINIO_BUCKET = NAME MINIO_LOCATION = us-east-1 MINIO_USE_SSL = true SERVE_DIRECT = true MINIO_ENDPOINT = s3.us-east-1.amazonaws.com ``` That works, I created a repo and cloned another I had at disposal with lfs config. I managed to commit and push all my lfs files and it uploaded everything on the s3. So that's great. But now I have an issue when cloning the repo, the clone does get the git files but when trying to get the lfs files on the s3 I get this message: `Error downloading object: FILE (hash): Smudge error: Error downloading FILE (hash): LFS: Get "https://NAME.s3.dualstack.us-east-1.amazonaws.com/lfs/PATHTOFILE": dial tcp: lookup NAME.s3.dualstack.us-east-1.amazonaws.com on IP:53: dial udp IP:53: socket: too many open files` From what I get it's only trying to get one file but even that doesn't work. Has anyone seen that before? ### Gitea Version 1.17.3 ### Can you reproduce the bug on the Gitea demo site? No ### Log Gist _No response_ ### Screenshots _No response_ ### Git Version _No response_ ### Operating System Debian ### How are you running Gitea? Installed gitea using one of the downloads, it is for testing purpose launched manually on foreground. ### Database PostgreSQL
GiteaMirror added the type/bugissue/workaround labels 2025-11-02 08:51:43 -06:00
GiteaMirror commented 2025-11-02 08:51:44 -06:00
Author
Owner
Copy Link

@lunny commented on GitHub (Nov 21, 2022):

Looks like it's a DNS problem not Gitea related.

@lunny commented on GitHub (Nov 21, 2022): Looks like it's a DNS problem not Gitea related.
GiteaMirror commented 2025-11-02 08:51:44 -06:00
Author
Owner
Copy Link

@night-gold commented on GitHub (Nov 21, 2022):

@lunny What makes you think it's DNS related?

@night-gold commented on GitHub (Nov 21, 2022): @lunny What makes you think it's DNS related?
GiteaMirror commented 2025-11-02 08:51:45 -06:00
Author
Owner
Copy Link

@lunny commented on GitHub (Nov 21, 2022):

From the log lookup NAME.s3.dualstack.us-east-1.amazonaws.com on IP:53: dial udp IP:53: socket: too many open files, I can see it failed when lookup the domain.

@lunny commented on GitHub (Nov 21, 2022): From the log `lookup NAME.s3.dualstack.us-east-1.amazonaws.com on IP:53: dial udp IP:53: socket: too many open files`, I can see it failed when lookup the domain.
GiteaMirror commented 2025-11-02 08:51:45 -06:00
Author
Owner
Copy Link

@night-gold commented on GitHub (Nov 29, 2022):

So I've been testing different things that did not works. I had to reinstall the gitea on an instance with public ip and no filter.

It changed the error but I still can't clone lfs files:
Error downloading object: PATH-TO-FILE (HASH): Smudge error: Error downloading PATH-TO-FILE (HASH): LFS: Get "https://NAME.s3.dualstack.us-east-1.amazonaws.com/lfs/HASH": dial tcp [2600:1fa0:8095:3948:34d8:fab0::]:443: connect: network is unreachable

The s3 is available I have access to it locally and the gitea has access, it could upload on it.
I have full access on the network of the instance, I opened every port, UDP and TCP on it and still nothing.

@night-gold commented on GitHub (Nov 29, 2022): So I've been testing different things that did not works. I had to reinstall the gitea on an instance with public ip and no filter. It changed the error but I still can't clone lfs files: ```Error downloading object: PATH-TO-FILE (HASH): Smudge error: Error downloading PATH-TO-FILE (HASH): LFS: Get "https://NAME.s3.dualstack.us-east-1.amazonaws.com/lfs/HASH": dial tcp [2600:1fa0:8095:3948:34d8:fab0::]:443: connect: network is unreachable``` The s3 is available I have access to it locally and the gitea has access, it could upload on it. I have full access on the network of the instance, I opened every port, UDP and TCP on it and still nothing.
GiteaMirror commented 2025-11-02 08:51:45 -06:00
Author
Owner
Copy Link

@lunny commented on GitHub (Nov 29, 2022):

So I've been testing different things that did not works. I had to reinstall the gitea on an instance with public ip and no filter.

It changed the error but I still can't clone lfs files: Error downloading object: PATH-TO-FILE (HASH): Smudge error: Error downloading PATH-TO-FILE (HASH): LFS: Get "https://NAME.s3.dualstack.us-east-1.amazonaws.com/lfs/HASH": dial tcp [2600:1fa0:8095:3948:34d8:fab0::]:443: connect: network is unreachable

The s3 is available I have access to it locally and the gitea has access, it could upload on it. I have full access on the network of the instance, I opened every port, UDP and TCP on it and still nothing.

But the error is obvious that network is unreachable.

@lunny commented on GitHub (Nov 29, 2022): > So I've been testing different things that did not works. I had to reinstall the gitea on an instance with public ip and no filter. > > It changed the error but I still can't clone lfs files: `Error downloading object: PATH-TO-FILE (HASH): Smudge error: Error downloading PATH-TO-FILE (HASH): LFS: Get "https://NAME.s3.dualstack.us-east-1.amazonaws.com/lfs/HASH": dial tcp [2600:1fa0:8095:3948:34d8:fab0::]:443: connect: network is unreachable` > > The s3 is available I have access to it locally and the gitea has access, it could upload on it. I have full access on the network of the instance, I opened every port, UDP and TCP on it and still nothing. But the error is obvious that `network is unreachable`.
GiteaMirror commented 2025-11-02 08:51:45 -06:00
Author
Owner
Copy Link

@night-gold commented on GitHub (Nov 29, 2022):

Totally, I've been asking for help because I can't read... Please don't post those type of answer... If you read the message you would have seen that:

  • I have full access on the network of the instance, I opened every port, UDP and TCP on it and still nothing.
  • I can access the s3 localy
  • The gitea can access the s3 as it could upload files.

The message doesn't tell me nothing and I've posted the error message as I have no idea where I should take a look at...

I didn't see those line in the log, but I've got them after the network error (During the same request for cloning):

error: le filtre externe 'git-lfs filter-process' a échoué
fatal: Assets/Plugins/SimpleFileBrowser/Sprites/Checkmark.psd : le filtre smudge 'lfs' a échoué
@night-gold commented on GitHub (Nov 29, 2022): Totally, I've been asking for help because I can't read... Please don't post those type of answer... If you read the message you would have seen that: - I have full access on the network of the instance, I opened every port, UDP and TCP on it and still nothing. - I can access the s3 localy - The gitea can access the s3 as it could upload files. The message doesn't tell me nothing and I've posted the error message as I have no idea where I should take a look at... I didn't see those line in the log, but I've got them after the network error (During the same request for cloning): ``` error: le filtre externe 'git-lfs filter-process' a échoué fatal: Assets/Plugins/SimpleFileBrowser/Sprites/Checkmark.psd : le filtre smudge 'lfs' a échoué ```
GiteaMirror commented 2025-11-02 08:51:45 -06:00
Author
Owner
Copy Link

@night-gold commented on GitHub (Nov 30, 2022):

Soooo... I finally found what was wrong... And it had nothing to do with the network. The error had something to do with the LFS conf and more precisely the SERVE_DIRECT option that was at TRUE. When I switched it to FALSE everything worked!

I don't really understand how this option created a network error and I lost a lot of time on it.

Putting the solution here if someone has the same issue in the futur.

@night-gold commented on GitHub (Nov 30, 2022): Soooo... I finally found what was wrong... And it had nothing to do with the network. The error had something to do with the LFS conf and more precisely the `SERVE_DIRECT` option that was at `TRUE`. When I switched it to `FALSE` everything worked! I don't really understand how this option created a network error and I lost a lot of time on it. Putting the solution here if someone has the same issue in the futur.
GiteaMirror commented 2025-11-02 08:51:46 -06:00
Author
Owner
Copy Link

@arychj commented on GitHub (Dec 12, 2022):

@night-gold's workaround is the only solution for gitea v1.7.3, but it looks like there was a regression introduced at some point between 1.15.8 and now. It should be fixed in 1.18.0.

@arychj commented on GitHub (Dec 12, 2022): @night-gold's workaround is the only solution for gitea v1.7.3, but it looks like there was a regression introduced at some point between [1.15.8 and now](https://github.com/go-gitea/gitea/issues/21525). It should be [fixed in 1.18.0](https://github.com/go-gitea/gitea/pull/21531).
GiteaMirror commented 2025-11-02 08:51:46 -06:00
Author
Owner
Copy Link

@artyomabgaryan commented on GitHub (Jan 5, 2023):

solution form night-gold doesn't work for me.. getting this when running server in test or dev mode`
Gitea: Internal Server Error
Get "https://localhost:3000/api/internal/serv/command/14/artyom/repo?mode=1&verb=git-upload-pack": dial tcp: lookup localhost on 192.168.1.1:53: no such host
fatal: Could not read from remote repository.
versions main (1.19.0 267) and 1.18 too

SOLUTION`
https://github.com/go-gitea/gitea/issues/21528#issuecomment-1312916855

@artyomabgaryan commented on GitHub (Jan 5, 2023): solution form night-gold doesn't work for me.. getting this when running server in test or dev mode` Gitea: Internal Server Error Get "https://localhost:3000/api/internal/serv/command/14/artyom/repo?mode=1&verb=git-upload-pack": dial tcp: lookup localhost on 192.168.1.1:53: no such host fatal: Could not read from remote repository. versions main (1.19.0 267) and 1.18 too SOLUTION` https://github.com/go-gitea/gitea/issues/21528#issuecomment-1312916855
GiteaMirror commented 2025-11-02 08:51:46 -06:00
Author
Owner
Copy Link

@jinyangcruise commented on GitHub (Jan 8, 2023):

SOLUTION`
https://discord.com/channels/322538954119184384/561007778139734027/1060668901656113283

first join gitea in discord then open this url, otherwise it shows nothing.

@jinyangcruise commented on GitHub (Jan 8, 2023): > SOLUTION` https://discord.com/channels/322538954119184384/561007778139734027/1060668901656113283 first join gitea in discord then open this url, otherwise it shows nothing.
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/workaround type/bug
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#9864
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?