Git pull - smudge filter lfs failed

Question

I'm attempting to pull code onto our server from Github (git pull origin master).

This worked before. However, now, I'm receiving the following error:

$ git pull origin master From github.com:org-name/repo-name  * branch              master     -> FETCH_HEAD Updating 8024663e..e458e5c1 fatal: path/to/file.msi: smudge filter lfs failed 

I ran the same command with GIT_TRACE=1:

$ GIT_TRACE=1 git pull origin master 19:25:26.331064 git.c:371               trace: built-in: git 'pull' 'origin' 'master' 19:25:26.333947 run-command.c:350       trace: run_command: 'fetch' '--update-head-ok' 'origin' 'master' 19:25:26.334661 exec_cmd.c:116          trace: exec: 'git' 'fetch' '--update-head-ok' 'origin' 'master' 19:25:26.337625 git.c:371               trace: built-in: git 'fetch' '--update-head-ok' 'origin' 'master' 19:25:26.344457 run-command.c:350       trace: run_command: 'ssh' '[email protected]' 'git-upload-pack '\''org-name/repo-name.git'\''' 19:25:26.925565 run-command.c:350       trace: run_command: 'rev-list' '--objects' '--stdin' '--not' '--all' '--quiet' 19:25:26.937016 run-command.c:350       trace: run_command: 'rev-list' '--objects' '--stdin' '--not' '--all' '--quiet' 19:25:26.937833 exec_cmd.c:116          trace: exec: 'git' 'rev-list' '--objects' '--stdin' '--not' '--all' '--quiet' 19:25:26.941292 git.c:371               trace: built-in: git 'rev-list' '--objects' '--stdin' '--not' '--all' '--quiet' From github.com:org-name/repo-name  * branch              master     -> FETCH_HEAD 19:25:26.994717 run-command.c:1130      run_processes_parallel: preparing to run up to 1 tasks 19:25:26.994880 run-command.c:1162      run_processes_parallel: done 19:25:26.995780 run-command.c:350       trace: run_command: 'gc' '--auto' 19:25:26.996735 exec_cmd.c:116          trace: exec: 'git' 'gc' '--auto' 19:25:27.000596 git.c:371               trace: built-in: git 'gc' '--auto' 19:25:27.002716 run-command.c:350       trace: run_command: 'merge' 'FETCH_HEAD' 19:25:27.003445 exec_cmd.c:116          trace: exec: 'git' 'merge' 'FETCH_HEAD' 19:25:27.006078 git.c:371               trace: built-in: git 'merge' 'FETCH_HEAD' Updating 8024663e..e458e5c1 19:25:27.420945 run-command.c:350       trace: run_command: 'git-lfs filter-process' 19:25:27.470865 run-command.c:209       trace: exec: '/bin/sh' '-c' 'git-lfs filter-process' 'git-lfs filter-process' trace git-lfs: run_command: 'git' version trace git-lfs: run_command: 'git' config -l trace git-lfs: Initialize filter-process trace git-lfs: Read filter-process request. trace git-lfs: Read filter-process request. fatal: path/to/file.msi: smudge filter lfs failed 19:25:27.998635 run-command.c:42        trace: run_command: running exit handler for pid 18022 

I verified my ssh credentials are correct:

$ ssh -T [email protected] Hi user-name! You've successfully authenticated, but GitHub does not provide shell access. 

And, in fact, I know the credentials are ok, because the pull will bring down the .gitattributes file (along with other small file changes I've done):

 file.msi filter=lfs diff=lfs merge=lfs -text 

I verified Git LFS appears to be configured correctly:

$ git config -l filter.lfs.process=git-lfs filter-process filter.lfs.required=true filter.lfs.clean=git-lfs clean -- %f filter.lfs.smudge=git-lfs smudge -- %f ... 

I found this Github issue, and I tried all three steps:

$ echo "protocol=https\nhost=github.com" | git credential fill $ echo "protocol=https\nhost=github.com" | git credential fill | git credential reject $ echo "protocol=https\nhost=github.com" | git credential fill | git credential approve 

The first step asked for my username. So, as it says, it doesn't appear that Git LFS is caching anything.

I don't have much experience with Git LFS, and frankly, I am out of ideas on how to approach this problem.

There are two actions I took recently that might have broken something:

1. I removed a user from our repository. The server's ssh key belonged to the user. We added a deployment key, but I read that Git LFS didn't support deployment keys (although, it appears that support was added recently). So, we switched to a user key. Both keys were confirmed with the ssh -T [email protected] test. Still, perhaps there's an authentication issue?
2. I pulled the repository down onto a server without Git LFS. I didn't realize it at the time, but the files transferred to the destination server fine. However, perhaps this broke something in the repository?

Any help you could lend would be greatly appreciated.

PS - I'm sorry if my anonymizing creates confusion. I replaced our actual IP address with X.X.X.X; our organization name with org-name; our repo name with repo-name; our Github user with user-name; the file name with file.msi; and, a few more things.

EDIT 5/16/17: Added language to make it clear that it used to work... and that I broke it.

Answer 1

In my case the SSH-authenticated repository was updated to use LFS from another client and on my side Git-LFS didn't know about the SSH remote-url. What I did to fix it was the following:

Copy the URL configured in remote.origin.url (push URL for origin) to lfs.url (the URL LFS uses):

$ git config lfs.url $(git config remote.origin.url) 

(If your remote is not named origin then change to your remote name.)

Then run

$ git config lfs.url 

to show the URL and confirm that it does indeed contain an SSH url, and not some HTTP/HTTPS url.

Then you can

$ git pull 

Done.

---

If you screwed up before and master and orgin/master have somehow diverged as was the case for me then you might need to git checkout -fB master origin/master (this doesn't ask and overwrites the local version of the master branch, so beware and execute carefully!).

See also: https://github.com/git-lfs/git-lfs/issues/2661#issuecomment-335903332

Answer 2

In my case, I have to add one more step after following the instructions provided by the answer by @grandchild. As explained by @grandchild, my remote git repo was changed to use protocol ssh from original https recently. In my git configuration, git configuration "http.sslverify" was not set originally. I believe the default value is true if it is missing. It caused the error "smudge filter lfs failed". Once I set it to false

$ git config http.sslverify false

It works without errors.