Git pull - smudge фильтр lfs не удалось

я пытаюсь вытащить код на наш сервер из Github (git pull origin master).

это раньше работало. Однако, теперь, я получаю следующую ошибку:

$ 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

я выполнил ту же команду с 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' 'git@github.com' '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

я проверил, что мои учетные данные ssh верны:

$ ssh -T git@github.com
Hi user-name! You've successfully authenticated, but GitHub does not provide shell access.

и, на самом деле, я знаю, что учетные данные в порядке, потому что pull сюда .gitattributes file (наряду с другими небольшими изменениями файлов у меня готово):

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

я проверил, что Git LFS настроен правильно:

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

я нашел это выпуск Github, и я попробовал все три шага:

$ echo "protocol=httpsnhost=github.com" | git credential fill
$ echo "protocol=httpsnhost=github.com" | git credential fill | git credential reject
$ echo "protocol=httpsnhost=github.com" | git credential fill | git credential approve

первый шаг попросил мое имя пользователя. Итак, как говорится, не похоже, что Git LFS кэширует что-либо.

у меня нет большого опыта работы с Git LFS, и, честно говоря, у меня нет идей о том, как подойти к этой проблеме.

есть два действия I взял недавно, что, возможно, что-то сломал:

1. я удалил пользователя из нашего хранилища. Ssh-ключ сервера принадлежал пользователю. Мы добавили ключ развертывания, но я прочитал это Git LFS не поддерживает ключи развертывания (хотя, похоже, что поддержка была добавлена недавно). Итак, мы переключились на пользовательский ключ. Оба ключа были подтверждены с