How to fix Object does not exist on the server: [404] in Git

GitINTERMEDIATEMEDIUMUpdated Jul 19, 2026· 375 views

This Git LFS error occurs when an LFS pointer file exists in your repository, but the actual binary file was never uploaded to the LFS server. The fix usually involves having the original author push the missing objects or recovering them during repository migration.

Quick fix

Fixes 404

git lfs ls-files --all
  1. Identify the missing LFS objects
  2. Ask the original author to push missing objects
  3. For repository migrations: fetch and push all LFS objects
  4. Try fetching all LFS objects
git — error
git lfs ls-files --all
Object does not exist on the server: [404]

What this error means

When you clone, pull, or checkout a repository that uses Git Large File Storage (LFS), Git LFS attempts to download large binary files from a separate LFS server. The repository contains "pointer files" that reference the actual content stored on the LFS server by its SHA-256 hash. This 404 error occurs when Git LFS finds a pointer file but cannot locate the corresponding binary object on the server. This typically happens because: 1. **The file was never properly uploaded** - The original contributor may not have had `git lfs install` configured, which means the pre-push hook that uploads LFS objects was not active. The pointer file got committed, but the actual binary content was never pushed to the LFS store. 2. **Repository migration issues** - When migrating between Git hosting providers (e.g., GitHub to GitLab, or between self-hosted instances), the standard `git clone` and `git push` commands only transfer the Git objects, not the LFS objects. Without special handling, LFS files are lost in the migration. 3. **The LFS object was deleted** - Some hosting providers have retention policies or manual cleanup processes that may have removed the object from LFS storage. The "smudge filter lfs failed" variant of this error appears when Git tries to convert an LFS pointer back to the actual file content during checkout - a process called "smudging."

Typical symptoms

  • Error message: 'Object does not exist on the server: [404] Object does not exist on the server'
  • Clone fails with 'Smudge error: Error downloading' followed by the object hash
  • Checkout or pull fails with 'fatal: smudge filter lfs failed'
  • Large binary files show as small text files containing SHA-256 hashes instead of actual content
  • git lfs fetch fails for specific files while others download successfully

Common causes

  1. The original contributor did not run 'git lfs install' before committing, so the pre-push hook was missing and objects were never uploaded
  2. Repository was migrated without including LFS objects (standard git clone/push doesn't transfer LFS data)
  3. The LFS object was deleted from the remote server due to storage policies or manual cleanup
  4. Interactive rebase or history rewriting orphaned LFS objects from their pointer files
  5. Network issues during the original push caused incomplete LFS upload (rare)
  6. Using a deprecated Git LFS API version that the server no longer supports

How to fix "Object does not exist on the server: [404]"

1Identify the missing LFS objects

First, determine which files are affected. Run:

bash
git lfs ls-files --all

Look for files marked with - (dash) instead of * (asterisk) - these are pointers without local objects.

To see which specific object is missing, check the error message for the SHA-256 hash, or run:

bash
git lfs fetch --all 2>&1 | grep "404"
2Ask the original author to push missing objects

If someone else committed the LFS files without proper setup, they likely still have the original files locally. Ask them to:

bash
# First, ensure LFS is installed
git lfs install

# Push all LFS objects to the server
git lfs push --all origin

If they have a specific object ID that's missing:

bash
git lfs push --object-id origin <oid>

Replace <oid> with the SHA-256 hash from the error message.

3For repository migrations: fetch and push all LFS objects

If you're migrating a repository, you must explicitly handle LFS objects. From the original (source) repository:

bash
# Clone with full LFS history from source
git clone <source-repo-url> repo-migration
cd repo-migration
git lfs fetch --all

# Add the new remote
git remote add new-origin <target-repo-url>

# Push everything including LFS
git push --mirror new-origin
git lfs push --all new-origin

Important: Run git lfs fetch --all before changing remotes to ensure all LFS objects are downloaded locally first.

4Try fetching all LFS objects

Sometimes the error occurs for only some objects. Try fetching everything:

bash
git lfs fetch --all

This downloads all LFS objects from all remote refs. If specific objects are truly missing from the server, they'll still fail, but this can resolve issues where objects exist but weren't fetched.

You can also try fetching from a specific branch or ref:

bash
git lfs fetch origin main
git lfs fetch origin --recent
5Check Git LFS version and configuration

Ensure your Git LFS client is up to date and not using deprecated API settings:

bash
# Check version
git lfs version

# Check for deprecated settings
git config -l | grep lfs

# Look for: lfs.batch = false (deprecated)

If you see lfs.batch = false, remove it:

bash
git config --unset lfs.batch

Update Git LFS to the latest version:

bash
# macOS
brew upgrade git-lfs

# Ubuntu/Debian
sudo apt-get update && sudo apt-get install git-lfs

# Windows (with Chocolatey)
choco upgrade git-lfs
6Skip LFS smudge for initial clone (workaround)

If you need to clone a repository but can't fix the missing LFS objects, you can skip the smudge filter:

bash
GIT_LFS_SKIP_SMUDGE=1 git clone <repo-url>

This clones the repository with LFS pointer files instead of actual content. Files tracked by LFS will be small text files containing hashes.

Later, you can selectively fetch LFS objects that do exist:

bash
cd <repo>
git lfs pull --include="path/to/specific/file.bin"
7Recover files manually (last resort)

If you have access to the file from another source (backup, original author, hosting provider's LFS management interface), you can manually place it:

1. Get the SHA-256 hash from the pointer file:

bash
cat path/to/file.bin
# Output shows: oid sha256:<hash>

2. Create the object directory structure:

bash
# Extract first 2 and next 2 characters of the hash
# Example hash: abc123def456...
mkdir -p .git/lfs/objects/ab/c1

3. Place the file in the correct location:

bash
cp /path/to/recovered/file .git/lfs/objects/ab/c1/abc123def456...

4. Run git lfs checkout to replace pointer with actual file:

bash
git lfs checkout path/to/file.bin
8Allow incomplete push for unrecoverable objects

If LFS objects are permanently lost and you need to continue working, you can configure Git LFS to allow pushing even with missing objects:

bash
git config lfs.allowincompletepush true

Warning: This should only be used when objects are confirmed unrecoverable. It allows your repository to remain functional but those specific files will be broken for anyone who clones.

Consider committing new versions of the affected files to replace the broken pointers.

Advanced notes

### Preventing This Error

To avoid this problem in the future:

1. Always run `git lfs install` first - This sets up the pre-push hook that automatically uploads LFS objects before Git pushes commits.

2. Verify LFS tracking before committing:

bash
git lfs track "*.psd"  # Track Photoshop files
git add .gitattributes  # Commit tracking rules first

3. For CI/CD pipelines, ensure LFS is installed in the build environment:

yaml
# GitHub Actions example
- uses: actions/checkout@v4
  with:
    lfs: true

### GitLab-Specific Issues

GitLab has known issues with LFS objects from forked repositories or merge requests. If you're using GitLab:

- LFS objects from forked repos may not be accessible after merge
- Check GitLab's LFS settings under Repository > Repository Settings
- Consider pushing LFS objects directly to the main repository

### Understanding LFS Pointer Files

A pointer file looks like this:

bash
version https://git-lfs.github.com/spec/v1
oid sha256:4d7a214614ab2935c943f9e0ff69d22eadbb8f32b1258daaa5e2ca24d17e2393
size 12345678

If you see this content instead of your binary file, Git LFS failed to "smudge" the pointer into the actual content.

### Hosting Provider LFS Management

Most Git hosting providers have LFS management interfaces:
- GitHub: Settings > Archives > Include Git LFS objects
- GitLab: Repository Settings > Repository > Git LFS
- Bitbucket: Repository settings > Git LFS

These interfaces can help you verify which objects exist and their sizes.

Frequently asked questions

What does "404" mean?
When you clone, pull, or checkout a repository that uses Git Large File Storage (LFS), Git LFS attempts to download large binary files from a separate LFS server. The repository contains "pointer files" that reference the actual content stored on the LFS server by its SHA-256 hash. This 404 error occurs when Git LFS finds a pointer file but cannot locate the corresponding binary object on the server.
How do I fix "404"?
This Git LFS error occurs when an LFS pointer file exists in your repository, but the actual binary file was never uploaded to the LFS server. The fix usually involves having the original author push the missing objects or recovering them during repository migration.
What causes "404"?
The original contributor did not run 'git lfs install' before committing, so the pre-push hook was missing and objects were never uploaded Repository was migrated without including LFS objects (standard git clone/push doesn't transfer LFS data) The LFS object was deleted from the remote server due to storage policies or manual cleanup
Is the "404" error serious?
It is a medium-severity error — more of a blocker than a risk. The steps above resolve it.

Official resources & further reading