# Failed LFS upload
**URL:**
**Author:**  [@chaoslde](/static-proxy?url=https%3A%2F%2Fdiscuss.huggingface.co%2Fu%2Fchaoslde)%5C
**Post date:** [April 9, 2026, 7:17am UTC](/static-proxy?url=https%3A%2F%2Fdiscuss.huggingface.co%2Ft%2Ffailed-lfs-upload%2F175109%2F1 "2026-04-09T07:17:56Z")
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
---
**Author:**  [@John6666](/static-proxy?url=https%3A%2F%2Fdiscuss.huggingface.co%2Fu%2FJohn6666)%5C
**Post date:** [April 9, 2026, 12:19pm UTC](/static-proxy?url=https%3A%2F%2Fdiscuss.huggingface.co%2Ft%2Ffailed-lfs-upload%2F175109%2F2 "2026-04-09T12:19:11Z")
> 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`](https://huggingface.co/docs/hub/storage-limits#super-squash-your-repository-using-the-api).
* * *
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](https://huggingface.co/docs/hub/storage-limits "Storage limits · 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](https://huggingface.co/docs/hub/storage-limits "Storage limits · 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](https://huggingface.co/docs/hub/storage-limits "Storage limits · 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](https://github.com/huggingface/huggingface_hub/issues/3048 "“Private repository storage limit reached” — quota shows space remaining · Issue #3048 · huggingface/huggingface\_hub · 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](https://huggingface.co/docs/hub/storage-limits "Storage limits · 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](https://github.com/huggingface/huggingface_hub/issues/3366 "Encountering HTTP 403 storage limit errors when uploading files · Issue #3366 · huggingface/huggingface\_hub · 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](https://github.com/huggingface/huggingface_hub/issues/3366 "Encountering HTTP 403 storage limit errors when uploading files · Issue #3366 · huggingface/huggingface\_hub · 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](https://huggingface.co/docs/hub/storage-limits "Storage limits · 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](https://huggingface.co/docs/hub/storage-limits "Storage limits · 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](https://github.com/huggingface/huggingface_hub/issues/3325 "Infinite retry loop in upload\_large\_folder when encountering HTTP 403 storage limit errors · Issue #3325 · huggingface/huggingface\_hub · 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](https://huggingface.co/docs/hub/storage-limits "Storage limits · 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](https://huggingface.co/docs/hub/storage-limits "Storage limits · 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](https://huggingface.co/docs/hub/storage-limits "Storage limits · 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](https://huggingface.co/docs/hub/storage-limits "Storage limits · 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](https://huggingface.co/docs/huggingface_hub/package_reference/hf_api "HfApi Client"))
### 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](https://huggingface.co/docs/hub/storage-limits "Storage limits · 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](https://huggingface.co/docs/hub/storage-limits "Storage limits · 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](https://github.com/huggingface/huggingface_hub/issues/3366 "Encountering HTTP 403 storage limit errors when uploading files · Issue #3366 · huggingface/huggingface\_hub · 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](https://huggingface.co/docs/hub/storage-limits "Storage limits · 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](https://github.com/huggingface/huggingface_hub/issues/3366 "Encountering HTTP 403 storage limit errors when uploading files · Issue #3366 · huggingface/huggingface\_hub · 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](https://github.com/huggingface/huggingface_hub/issues/3048 "“Private repository storage limit reached” — quota shows space remaining · Issue #3048 · huggingface/huggingface\_hub · GitHub"))
## A practical recovery sequence
Do this in this order:
1. **Do not retry again yet.** ([GitHub](https://github.com/huggingface/huggingface_hub/issues/3325 "Infinite retry loop in upload\_large\_folder when encountering HTTP 403 storage limit errors · Issue #3325 · huggingface/huggingface\_hub · GitHub"))
2. **Read the exact 403 text carefully.**
3. **Open Settings → Storage → List LFS files.** ([Hugging Face](https://huggingface.co/docs/hub/storage-limits "Storage limits · Hugging Face"))
4. **Delete stale LFS objects you do not need.** ([Hugging Face](https://huggingface.co/docs/huggingface_hub/package_reference/hf_api "HfApi Client"))
5. **Delete stale PR refs if they exist.** ([Hugging Face](https://huggingface.co/docs/hub/storage-limits "Storage limits · Hugging Face"))
6. **Use `super_squash_history` if the repo accumulated many old large revisions.** ([Hugging Face](https://huggingface.co/docs/hub/storage-limits "Storage limits · Hugging Face"))
7. **Wait for quota/accounting to catch up if you squashed.** Hugging Face says this can take **within 36 hours**. ([Hugging Face](https://huggingface.co/docs/hub/storage-limits "Storage limits · 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](https://huggingface.co/docs/hub/storage-limits "Storage limits · Hugging Face"))
9. **If you are in the “storage patterns” branch, email support with the exact message and repo details.** ([GitHub](https://github.com/huggingface/huggingface_hub/issues/3366 "Encountering HTTP 403 storage limit errors when uploading files · Issue #3366 · huggingface/huggingface\_hub · 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](https://huggingface.co/docs/hub/storage-limits "Storage limits · Hugging Face"))
---
**Author:**  [@chaoslde](/static-proxy?url=https%3A%2F%2Fdiscuss.huggingface.co%2Fu%2Fchaoslde)%5C
**Post date:** [April 9, 2026, 12:47pm UTC](/static-proxy?url=https%3A%2F%2Fdiscuss.huggingface.co%2Ft%2Ffailed-lfs-upload%2F175109%2F3 "2026-04-09T12:47:16Z")
thank you for you response.
ill look into it.