{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreihmq3msohdjxk2rtojqeyejpye7p7nvqusbdynf24axfcgh2vpela",
    "uri": "at://did:plc:pgryn3ephfd2xgft23qokfzt/app.bsky.feed.post/3mj2vdcqhhlc2"
  },
  "path": "/t/failed-lfs-upload/175109#post_2",
  "publishedAt": "2026-04-09T12:19:11.000Z",
  "site": "https://discuss.huggingface.co",
  "tags": [
    "super_squash_history",
    "Hugging Face",
    "GitHub"
  ],
  "textContent": "> Can you activate manual garbage collection in my account ?\n\nFirst, there are **two completely different types of 403 errors** that frequently occur in HF.\nIf the issue is caused by accumulated LFS junk, the simplest solution is for the user to run super_squash_history.\n\n* * *\n\nWhat you should do depends on the **exact 403 message** , but the core answer is this:\n\n**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)\n\n## What probably happened\n\nHugging 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)\n\nSo if your upload “broke a few times,” the likely failure mode is:\n\n  * some large objects may actually have landed,\n  * retries may have created more retained LFS objects or history,\n  * and now a later push is blocked by storage enforcement or account-side review. (Hugging Face)\n\n\n\n## There are two main 403 branches\n\n### Branch A. The error says something like `Private repository storage limit reached`\n\nThat 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)\n\nIn this branch, the most likely causes are:\n\n  * retained LFS objects from failed or repeated uploads,\n  * old history still referencing large files,\n  * PR refs or branches still pointing at those objects,\n  * or quota accounting that has not caught up yet. (Hugging Face)\n\n\n\n### Branch B. The error says `Your storage patterns tripped our internal systems`\n\nThat 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)\n\nIn this branch, the likely interpretation is:\n\n  * the account got flagged by automated storage-abuse protections,\n  * especially after repeated large uploads or retry behavior,\n  * 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)\n\n\n\n## Why “manual garbage collection” is probably the wrong mental model\n\nOn 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** :\n\n  * delete actual LFS files from **List LFS files** ,\n  * delete PR refs that still retain large objects,\n  * or use **super_squash_history** to compress history. (Hugging Face)\n\n\n\nSo 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)\n\n## What I would do now\n\n### 1. Stop retrying the same upload\n\nThere 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)\n\n### 2. Check whether the repo is public or private\n\nThis matters because Hugging Face’s storage page currently says:\n\n  * **Free public storage:** best-effort\n  * **Free private storage:** 100 GB (Hugging Face)\n\n\n\nIf 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)\n\n### 3. Inspect the repo’s actual LFS objects\n\nGo to:\n\n**Repository → Settings → Storage → List LFS files**\n\nHugging Face explicitly documents this as the place to inspect and delete real LFS files, and says deleting only pointers is not enough. (Hugging Face)\n\nWhat you are looking for:\n\n  * duplicate model shards,\n  * half-finished upload artifacts,\n  * old checkpoints,\n  * files with large sizes you no longer need,\n  * files whose names look stale or repeated. (Hugging Face)\n\n\n\n### 4. Delete the real LFS objects you no longer need\n\nIf 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)\n\n### 5. Delete stale PR refs if any exist\n\nHugging 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)\n\n### 6. If the repo has many old large versions, use `super_squash_history`\n\nHugging 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)\n\n### 7. If the exact message is the “storage patterns” one, contact support\n\nIn that case, I would not rely only on cleanup. I would email `website@huggingface.co` with:\n\n  * your username,\n  * repo ID,\n  * whether it is public or private,\n  * exact 403 text,\n  * whether you used the website, `hf upload`, `upload_large_folder`, `git push`, or `push_to_hub`,\n  * approximate total model size,\n  * number of retries,\n  * and whether you already checked **List LFS files**. (GitHub)\n\n\n\n## The most likely diagnosis for your case\n\nGiven your description alone, without the exact error text, my ranking is:\n\n### Most likely\n\nA **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)\n\n### Second most likely\n\nAn **account-side storage flag** if the message says “storage patterns tripped our internal systems.” Public reports show that exact behavior. (GitHub)\n\n### Less likely\n\nA 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)\n\n## A practical recovery sequence\n\nDo this in this order:\n\n  1. **Do not retry again yet.** (GitHub)\n\n  2. **Read the exact 403 text carefully.**\n\n     * If it says **private repository storage limit reached** , think cleanup/history. (GitHub)\n     * If it says **storage patterns tripped our internal systems** , think support review. (GitHub)\n  3. **Open Settings → Storage → List LFS files.** (Hugging Face)\n\n  4. **Delete stale LFS objects you do not need.** (Hugging Face)\n\n  5. **Delete stale PR refs if they exist.** (Hugging Face)\n\n  6. **Use`super_squash_history` if the repo accumulated many old large revisions.** (Hugging Face)\n\n  7. **Wait for quota/accounting to catch up if you squashed.** Hugging Face says this can take **within 36 hours**. (Hugging Face)\n\n  8. **Re-upload in smaller pieces.** Hugging Face recommends around **50 to 100 files per commit** and smaller chunks for large uploads. (Hugging Face)\n\n  9. **If you are in the “storage patterns” branch, email support with the exact message and repo details.** (GitHub)\n\n\n\n\n## Bottom line\n\nMy answer is:\n\n  * **No obvious public “manual garbage collection for my account” flow exists.**\n  * **Yes, this is a known kind of Hugging Face failure pattern.**\n  * **Your next step is either repo cleanup or support review, depending on the exact 403 wording.** (Hugging Face)\n\n",
  "title": "Failed LFS upload"
}