Git

How to Fix Git LFS "Download Failed" on Clone Due to Bandwidth Quota Exceeded

4 min read by DebuggedIt

Quick answer

Cloning or pulling a repository that uses Git LFS fails partway through, specifically on the large file download step, with an error pointing at exceeded...

Cloning or pulling a repository that uses Git LFS fails partway through, specifically on the large file download step, with an error pointing at exceeded bandwidth. Unlike regular Git objects, LFS-tracked files are billed and rate-limited separately by most hosting providers, and this error means your account (or the repository owner's account) has hit that specific limit.

The Problem

A clone that starts normally fails specifically during the LFS file download phase:

$ git clone https://github.com/youruser/yourrepo.git
Cloning into 'yourrepo'...
remote: Enumerating objects: 1203, done.
...
Filtering content: 45% (89/198), 412.35 MiB | 2.1 MiB/s
error: external filter 'git-lfs filter-process' failed
fatal: yourrepo/assets/video1.mp4: smudge filter lfs failed

Running the LFS pull command directly gives a more explicit reason:

$ git lfs pull
batch response: This repository is over its data quota. Purchase more data packs to restore access.
error: failed to fetch some objects from 'https://github.com/youruser/yourrepo.git/info/lfs'

Why It Happens

Git LFS stores large files outside the normal Git object database, and most hosting providers (GitHub, GitLab, Bitbucket) meter LFS storage and bandwidth separately from regular Git usage, often with a much smaller free-tier allowance. This error means the relevant quota — either storage (how much LFS data the repository holds) or bandwidth (how much has been downloaded within a billing period) — has been exceeded for the account that owns the repository. Common causes:

  • Many contributors or CI runners repeatedly cloning the same LFS-tracked repository, each full clone consuming bandwidth quota, quickly adding up on a free or lower-tier plan.
  • Large binary assets committed to LFS growing over time without any cleanup of old, no-longer-needed versions, since every version of every tracked file typically still counts against storage quota.
  • CI/CD pipelines cloning the full repository (including LFS files) on every single build, rather than caching or selectively fetching only what's actually needed for that specific job.
  • The quota resets on a monthly billing cycle, and the limit was simply reached partway through the current period due to cumulative usage.

The Fix

If you own or administer the repository, the most direct fix is purchasing additional LFS data packs (GitHub's terminology) or upgrading to a plan with higher included quota, since this is fundamentally a billing/quota limit rather than a technical misconfiguration:

# Check current LFS usage in your GitHub account settings under
# Settings -> Billing and plans -> Git LFS Data

If you're a contributor without billing access, coordinate with the repository owner, since only they can resolve the quota at the source — no client-side Git configuration can bypass a genuine provider-side quota limit.

To reduce future bandwidth consumption regardless of who owns the quota, avoid unnecessary full clones where a shallower or partial fetch would work just as well. For CI specifically, clone without pulling LFS content immediately, then selectively fetch only what a given job actually needs:

GIT_LFS_SKIP_SMUDGE=1 git clone https://github.com/youruser/yourrepo.git
cd yourrepo
git lfs pull --include="specific-file-needed.mp4"

For CI pipelines that run frequently, cache the LFS objects between runs rather than re-downloading them on every single build, since repeated identical downloads are often the single biggest contributor to hitting bandwidth quotas:

# Example: GitHub Actions caching LFS objects between runs
- uses: actions/cache@v4
  with:
    path: .git/lfs
    key: lfs-${{ hashFiles('.gitattributes') }}

Audit what's actually stored in LFS and whether old, unused versions can be pruned to reduce ongoing storage costs, which indirectly helps avoid repeatedly hitting storage-adjacent limits:

git lfs ls-files
git lfs prune

git lfs prune removes old LFS objects that are no longer referenced by any recent commit from your local cache — for actually reducing quota usage at the hosting provider level, you'd need to look at that provider's specific tools for managing historical LFS object retention, since local pruning alone doesn't reduce what's stored remotely.

Still Not Working?

If you need to unblock your own work immediately and don't have the ability to resolve the underlying quota (for example, working with an open-source repository whose maintainer hasn't yet addressed it), consider whether you actually need every LFS-tracked file for your specific task — cloning without LFS content entirely lets you work with the rest of the repository normally while skipping the files you don't currently need:

GIT_LFS_SKIP_SMUDGE=1 git clone https://github.com/youruser/yourrepo.git

Files that would normally be smudged into their actual content instead remain as small LFS pointer text files, which is often sufficient if your work doesn't actually require opening or using those specific large binary assets.

You might also like