Git LFS "unable to lock ... locking not supported" in CI

By Kaveh Alemi·Latchkey

A git lfs lock call or a push with lock verification hit a remote that does not support the LFS locking API. The operation cannot acquire or verify the lock, so it errors.

What this error means

git lfs lock or a push fails with "unable to lock" or "Remote does not support the LFS locking API" in a CI job that touches LFS-tracked files.

Remote "origin" does not support the Git LFS locking API.
Unable to lock: assets/design.psd

Common causes

The remote lacks LFS locking support

Not every LFS server implements locking. A lock or lock-verify call against such a remote cannot be honored.

CI runs a locking step that is not needed

A workflow copied from a locking-enabled setup calls lock commands that fail where locking is unavailable.

How to fix it

Disable lock verification and drop lock steps

1. Set git config lfs.locksverify false so pushes do not attempt verification.
2. Remove git lfs lock/unlock steps from jobs on a non-locking remote.
3. Re-run the workflow.

git config lfs.locksverify false

Only lock against a supporting remote

If you need locking, target a server that implements the LFS locking API; otherwise treat locks as unavailable in CI.

Using this in CI

CI checkouts are shallow and detached by default, which changes the answer this command gives you. Commands that read history, branch names, or tags need the checkout configured for it.

- uses: actions/checkout@v4
  with:
    fetch-depth: 0   # history, tags, and git describe all need this

- run: |
    git rev-parse --is-shallow-repository   # expect false
    git rev-parse --abbrev-ref HEAD          # prints HEAD when detached

How to prevent it

• Set lfs.locksverify false on remotes without locking support.
• Keep lock/unlock steps out of jobs where locking is unavailable.
• Document which remotes support LFS locking.

Frequently asked questions

Related guides

References

• Git reference manual
• GitHub Actions documentation