0

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?

night-gold
  • 133
  • 8

1 Answers1

0

I was having the same issue, though I'm not sure what the root cause is. It appears that something in the git-lfs client doesn't like the direct/signed S3 URLs gitea is serving.

My solution was setting SERVE_DIRECT = false, which basically proxies all the LFS objects back through gitea before returning them to the client.

Erik J. Olson
  • 116
  • 1
  • So while this workaround is the only solution for gitea v1.7.3, 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). – Erik J. Olson Dec 12 '22 at 23:54
  • Totally forgot that I had posted here... I also created an issue on gitea github and gave the workaround there also. will still accept your answer ;) – night-gold Dec 14 '22 at 13:30