git-lfs aborts with "LFS: Git credentials for https://XXX not found." even for repositories without passwords

[etc0de]

When run non-interactively, git-lfs pull aborts with "LFS: Git credentials for https://XXX not found." even for repositories _without_ any password protection.
When run interactively, it will download files correctly but prompt you a thousand times needlessly for some password which can be "fixed" by hitting the return key like an insane person.

To reproduce the bug, do the following setup:

mkdir blah
cd blah
git init .
git lfs install --skip-smudge .
git remote add origin https://<url removed>
git remote update
git pull origin master

Now run in that folder the following command non-interactively: git lfs pull origin master
The repository is public and not password protected in any way, so obviously it should work. However, the result is: "LFS: Git credentials for https:// not found."

(Alternatively, run it interactively and see a useless password prompt madness.)

A workaround would be highly appreciated, because this is preventing me from doing an automated deployment.

---

Expected behavior:

Non-interactively: at least _try without a password once_ instead of giving up with no good reason.

Interactively: if I just hit enter throughout the first prompts and the download works, asking me a thousand times for absolutely nothing is a bit silly (although I guess that gets better when using a credentials cache)

[etc0de]

"Funny" trivia:

I tried to reproduce this in bash instead of my custom non-interactive server script, but even with </dev/null >/dev/null 2>&1 or wrapping it with python3 -c "import subprocess; import sys; result = subprocess.call(['git', 'lfs', 'pull', 'origin', 'master']); sys.exit (result) will make git / git-lfs find and grab the terminal and spam me with password prompts. Which also seems like kinda bad (or at least weird!) and unexpected behavior to me - if I'm running it with another stdin, I'm certainly not expecting a prompt, but oh well..

[technoweenie]

Did your repository change permissions? By default, Git LFS won't ask any credentials. If the LFS server sends back a 401, Git LFS assumes the repository needs creds and sets lfs.<url>.access. Your local git config should have something like:

lfs.https://gitlab.wobble.ninja/JonasT/wobbly.git/info/lfs.access=basic

You can clear that key with git config --unset lfs.https://gitlab.wobble.ninja/JonasT/wobbly.git/info/lfs.access.

If that doesn't help, can you post GIT_TRACE=1 output?

[etc0de]

I tested this on two machines with one of them being a docker environment with freshly installed git-lfs in the latest version, so it's not a client config issue. This can be reproduced easily with any fresh git-lfs install given the instructions above.

As for the server, it's just how gitlab LFS server configures and serves the repo per default. I can't really influence that, and I didn't change anything - at least I'm not aware of it. (Changing git settings of a repo on a gitlab server is kinda difficult anyway)

[technoweenie]

Ah, I meant your local repo git config, not your server's.

Can you post GIT_TRACE=1 git pull origin master output for a fresh run? This looks like https://github.com/github/git-lfs/issues/1330, which is due to a problem in gitlab's lfs server http responses. The GIT_TRACE=1 output will show if that's happening here too.

[technoweenie]

Ah, different issue. The server needs to be updated to return authenticated: true for objects that don't need authentication. /cc https://github.com/github/git-lfs/pull/1452

[etc0de]

The merge request sounds like this was supposed to be backwards compatible. However, it does seem to break non-interactive lfs pulls? (edit: unless this never worked properly before, of course)

Edit2: one of my test git-lfs is way older than that merge though. So I guess this never worked properly, but it will once gitlab updates their server? That'd certainly be nice, although the workaround works for me for now

[technoweenie]

unless this never worked properly before, of course

Er nope :/

I think the suggestion in https://github.com/github/git-lfs/issues/1330#issuecomment-228803900 could make the client smarter about asking multiple times in a single command, without requiring the changes to the server.

[technoweenie]

Thanks for the update! Closing this, as there's nothing on the client to fix.

[axonetric]

For those experiencing this issue on Windows, I found the following command fixes it:

git config --global credential.helper cache

[Canadauni]

In my case on Windows using gitbash I had to use:
git config --global credential.helper wincred

[shopglobal]

Thank you @Canadauni
For Windows, this is still confirmed solution.

[davidlenz]

@Canadauni's solution worked for me.

[NikoBele1]

Same for me with @Canadauni's line

[brianagina]

Canadauni, you are a life saver!

[Castern]

git config --global credential.helper cache

Worked for me. Thank You!