-
This is a bug in OneDev, not a configuration or project-naming issue.
The SSH
git-lfs-authenticatehook builds the LFShrefby taking the project's HTTP clone URL and appending.git/info/lfs. Clone URLs already end with.git, so the result is a doubled suffix:https://g1t.my.domain/GK/frontend-unity.git+.git/info/lfs
→https://g1t.my.domain/GK/frontend-unity.git.git/info/lfsThat matches the JSON you captured. It also explains why the same
.git.githref is returned whether you passGK/frontend-unity.gitorGK/frontend-unityon the SSH command: the href is taken from the resolved project's clone URL, not from the path you typed.Your k3s manifest is not the cause.
initial_server_url/initial_ssh_root_urllook correct, and Ingress/SSH port mapping does not affect how that href is constructed.The workaround you already found is the right local fix until this is corrected on the server:
git config lfs.url "https://g1t.my.domain/GK/frontend-unity.git/info/lfs"That bypasses SSH endpoint discovery and points Git LFS at the valid HTTP URL.
Related: HTTP LFS path parsing was later taught to accept
.git.git(see #2612), but the SSH authenticate hook still emits the doubled URL, so Git LFS can still fail with 401/403 against that href. -
Thank you for the fast answer. I am sorry for not finding the related issue. Closed
-
Previous Value Current Value Open
Closed
-
-
AI generated suggested fixes, looks good for me, so i want to add this information here: (i personally woud prefer the second fix, if you are not hosting a large OneDev solution with manny LFS projects)
The Kubernetes Fix (Traefik URL Rewrite)
- Create the Middleware
Add this Traefik ReplacePathRegex middleware to your cluster. It captures the double .git.git in the URL and strips the extra one
out.
apiVersion: traefik.containo.us/v1alpha1 # Note: If your Traefik is newer, this might be apiVersion: traefik.io/v1alpha1 kind: Middleware metadata: name: onedev-lfs-fix namespace: onedev spec: replacePathRegex: regex: "^/(.*)\\.git\\.git/info/lfs(.*)" replacement: "/$1.git/info/lfs$2"- Attach it to your Ingress Update your onedev-ingress in onedev.yaml to include this new middleware. You append it to the router.middlewares annotation using the format -@kubernetescrd.
Update this section of your onedev.yaml:
annotations: cert-manager.io/cluster-issuer: letsencrypt-prod # Add the new middleware to the list: traefik.ingress.kubernetes.io/router.middlewares: default-redirect-https@kubernetescrd, onedev-onedev-lfs-fix@kubernetescrdApply both changes with kubectl apply -f. Once applied, when the SSH hook gives Git LFS the .git.git URL, your Traefik proxy will
silently fix the URL, OneDev will authenticate it perfectly, and git lfs pull will succeed for everyone! ──────Alternative: The Repository Fix (.lfsconfig)
If you'd rather not mess with Traefik, you can fix this at the project level by committing a .lfsconfig file to the root of your
git repository.Create a file named .lfsconfig in your project containing:
[lfs] url = "https://g1t.my.domain/GK/frontend-unity.git/info/lfs"Once you commit and push this file, anyone who clones the repository will automatically use the correct URL, overriding the broken one returned by the SSH hook. (Git LFS will still properly negotiate the SSH authentication token in the background).
- Create the Middleware
-
Thanks for adding these. A few clarifications so the workarounds are not misleading:
.lfsconfigis a repo-level form of thelfs.urlworkaround you already used. Settinglfs.urloverrides SSH endpoint discovery. Git LFS will not still callgit-lfs-authenticatein the background for that URL; it talks to the HTTPS LFS endpoint with HTTP credentials (access token / password), not the SSH bearer token. A committed.lfsconfigalso hardcodes the server host, so clones via a different hostname will keep using that URL.Traefik
replacePathRegexcan work as an ingress-level workaround: the client still requests the doubled.git.githref, and Traefik rewrites the path before it reaches OneDev. On current OneDev, HTTP LFS already accepts.git.git(see issue #2612), so a rewrite is only needed on an older version, or if something in front of OneDev rejects that path. Use the Traefik CRD API group that matches your Traefik version (traefik.iovstraefik.containo.us).Neither change is required in OneDev itself. The remaining server-side issue is the SSH hook emitting
.git.git; the locallfs.urlworkaround remains the straightforward client-side fix. -
Oh sorry, this is my fault for not thinking and just using AI.
I now understand that this issue only appears with ssh + lfs. Thank you for explaining it again for this stupid person.
For me the .lfsconfig is important, because we only use ssh pull, and if we pull from a new system, i do not want to think about configuring lfs.url again.
Thank you for the fast answers. Greetings
-
Reopen as this is actually a bug.
-
Previous Value Current Value Closed
Open
-
Name Previous Value Current Value Type
Question
Bug
Affected Versions
empty <=16.5.5
-
Previous Value Current Value Is the SSH LFS hook generating a double .git.git endpoint URL a bug or a configuration issue?
SSH LFS hook generating double .git.git endpoint URL
-
State changed as build OD-8227 (16.5.6) is successful
-
OneDev
changed state to 'Closed' 3 days ago
Previous Value Current Value Open
Closed
| Type |
Bug
|
| Priority |
Normal
|
| Assignee | |
| Affected Versions |
<=16.5.5
|
| Labels |
No labels
|
I've run into an issue with Git LFS after a recent update where git lfs pull fails with an "Authorization error". I noticed that the failure happens because the Git LFS client is being directed to a URL that contains a double .git.git suffix.
I'm not sure if this is a bug introduced in a recent OneDev release, or if it's caused by my specific configuration/project naming.
Technical Details:
My repository is cloned via SSH, and the remote in my .git/config is standard:
When Git LFS attempts to negotiate the HTTP endpoint over SSH, OneDev returns an href with .git.git:
Interestingly, even if I test the SSH hook without the .git suffix, the server still returns the double .git.git URL:
Because of this response, the local Git client attempts to download LFS objects from https://g1t.my.domain/GK/frontend- unity.git.git/info/lfs/objects/batch, which fails with a 401/403 Authorization Error because the path does not match the
actual repository.
Temporary Workaround: I was able to get my local client working again by forcing the correct lfs.url in my .git/config, bypassing the SSH
endpoint negotiation:
Question: Is this a known issue with how the LFS href is constructed in recent versions? Or is this an expected behavior resulting
from a misconfiguration in my server setup or the way my project is named?
For context, here is the .yaml configuration I use for hosting OneDev on k3s: