Failed LFS upload

Beginners
1

Hi team,

Can you help me out please?

I am trying to upload my model into a free account and The upload broke a few times.

and now i am getting a 403 storage error message.

Can you activate manual garbage collection in my account ?

Thanks in advance

1 Like
2

Can you activate manual garbage collection in my account ?

First, there are two completely different types of 403 errors that frequently occur in HF.
If the issue is caused by accumulated LFS junk, the simplest solution is for the user to run super_squash_history.

What you should do depends on the exact 403 message, but the core answer is this:

There is no normal user-facing “manual garbage collection” switch for an account. On Hugging Face, the documented ways to free storage are to delete actual LFS objects from the repo’s Settings → Storage → List LFS files, delete stale PR refs that still keep large objects alive, or run super_squash_history to rewrite history. Hugging Face also notes that deleting only the current LFS pointers does not free space, and that storage quota updates after a squash can take up to 36 hours to show. (Hugging Face)

What probably happened

Hugging Face Hub repos are still Git-backed. Large files are stored through LFS, but the repo still has history, refs, and commit structure. Because of that, a failed upload is not always a clean no-op. Hugging Face explicitly says that for HTTP uploads there is a 60-second timeout, and in rare cases the client can time out even though the server-side process still completed. They recommend about 50 to 100 files per commit to reduce that risk. (Hugging Face)

So if your upload “broke a few times,” the likely failure mode is:

  • some large objects may actually have landed,
  • retries may have created more retained LFS objects or history,
  • and now a later push is blocked by storage enforcement or account-side review. (Hugging Face)

There are two main 403 branches

Branch A. The error says something like Private repository storage limit reached

That is the normal quota-style branch. There is a public Hugging Face Hub issue where a user got exactly that 403 while the UI still showed only about 61 GB used out of 100 GB. That means visible quota and backend enforcement can diverge in real cases. (GitHub)

In this branch, the most likely causes are:

  • retained LFS objects from failed or repeated uploads,
  • old history still referencing large files,
  • PR refs or branches still pointing at those objects,
  • or quota accounting that has not caught up yet. (Hugging Face)

Branch B. The error says Your storage patterns tripped our internal systems

That is a different branch. A recent public issue shows that exact message and says Hugging Face asks the user to contact website@huggingface.co so they can verify the account and unlock more storage for the use case. That is not ordinary “you simply ran out of free quota.” (GitHub)

In this branch, the likely interpretation is:

  • the account got flagged by automated storage-abuse protections,
  • especially after repeated large uploads or retry behavior,
  • and self-service cleanup alone may not be enough until support reviews the account. This last sentence is an inference, but it is strongly supported by the wording of the error and the support instruction attached to it. (GitHub)

Why “manual garbage collection” is probably the wrong mental model

On Hugging Face, the public docs do not present storage cleanup as an account-wide garbage-collection action done on request. They present it as repo-level cleanup:

  • delete actual LFS files from List LFS files,
  • delete PR refs that still retain large objects,
  • or use super_squash_history to compress history. (Hugging Face)

So if you ask support for “manual garbage collection,” they may understand what you mean, but the practical recovery steps are usually one of those documented repo actions, or account review if you hit the “storage patterns” branch. (Hugging Face)

What I would do now

1. Stop retrying the same upload

There is an open Hugging Face Hub issue showing upload_large_folder can get stuck in an infinite retry loop on storage-related 403 errors, rehashing and retrying even though retries cannot solve the underlying storage block. More retries are unlikely to help and may make the situation harder to reason about. (GitHub)

2. Check whether the repo is public or private

This matters because Hugging Face’s storage page currently says:

  • Free public storage: best-effort
  • Free private storage: 100 GB (Hugging Face)

If your repo is private, the “private repository storage limit reached” branch becomes more plausible. If it is public, and especially if the model is large, the “storage patterns” branch becomes more plausible. That is not a guarantee, but it is the right weighting from the public docs and issues. (Hugging Face)

3. Inspect the repo’s actual LFS objects

Go to:

Repository → Settings → Storage → List LFS files

Hugging Face explicitly documents this as the place to inspect and delete real LFS files, and says deleting only pointers is not enough. (Hugging Face)

What you are looking for:

  • duplicate model shards,
  • half-finished upload artifacts,
  • old checkpoints,
  • files with large sizes you no longer need,
  • files whose names look stale or repeated. (Hugging Face)

4. Delete the real LFS objects you no longer need

If the bad uploads left old objects behind, this is the first direct cleanup step. Hugging Face’s API docs say list_lfs_files() exists specifically to count repo storage use, and permanently_delete_lfs_files() exists to remove those objects. They also warn that this is permanent and can affect all commits that reference those files. (Hugging Face)

5. Delete stale PR refs if any exist

Hugging Face docs say closed or merged PRs can still hold git refs that keep storage alive, and those refs can be deleted from the PR UI to free space. (Hugging Face)

6. If the repo has many old large versions, use super_squash_history

Hugging Face documents super_squash_history as the official way to compress history into one commit and reclaim storage from old LFS versions. It is destructive and non-revertible. Storage quota reflection can take up to 36 hours after the squash. (Hugging Face)

7. If the exact message is the “storage patterns” one, contact support

In that case, I would not rely only on cleanup. I would email website@huggingface.co with:

  • your username,
  • repo ID,
  • whether it is public or private,
  • exact 403 text,
  • whether you used the website, hf upload, upload_large_folder, git push, or push_to_hub,
  • approximate total model size,
  • number of retries,
  • and whether you already checked List LFS files. (GitHub)

The most likely diagnosis for your case

Given your description alone, without the exact error text, my ranking is:

Most likely

A repo-history / LFS-retention problem caused by repeated failed uploads, especially if the message is about repository storage limit. Hugging Face’s storage model and timeout behavior fit this very well. (Hugging Face)

Second most likely

An account-side storage flag if the message says “storage patterns tripped our internal systems.” Public reports show that exact behavior. (GitHub)

Less likely

A generic auth or permission issue. Your description points much more strongly to storage enforcement than to bad credentials. The public issues you resemble are storage-specific 403s, not ordinary auth failures. (GitHub)

A practical recovery sequence

Do this in this order:

  1. Do not retry again yet. (GitHub)

  2. Read the exact 403 text carefully.

    • If it says private repository storage limit reached, think cleanup/history. (GitHub)
    • If it says storage patterns tripped our internal systems, think support review. (GitHub)

  3. Open Settings → Storage → List LFS files. (Hugging Face)

  4. Delete stale LFS objects you do not need. (Hugging Face)

  5. Delete stale PR refs if they exist. (Hugging Face)

  6. Use super_squash_history if the repo accumulated many old large revisions. (Hugging Face)

  7. Wait for quota/accounting to catch up if you squashed. Hugging Face says this can take within 36 hours. (Hugging Face)

  8. Re-upload in smaller pieces. Hugging Face recommends around 50 to 100 files per commit and smaller chunks for large uploads. (Hugging Face)

  9. If you are in the “storage patterns” branch, email support with the exact message and repo details. (GitHub)

Bottom line

My answer is:

  • No obvious public “manual garbage collection for my account” flow exists.
  • Yes, this is a known kind of Hugging Face failure pattern.
  • Your next step is either repo cleanup or support review, depending on the exact 403 wording. (Hugging Face)
3

thank you for you response.

ill look into it.

1 Like