Git pull - smudge filter lfs failed

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:

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?
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.

Solution

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 main and origin/main have somehow diverged as was the case for me then you might need to git checkout -fB main origin/main (this doesn't ask and overwrites the local version of the main branch, so beware and execute carefully!).