unslothai/unsloth · error · HTTPException

Failed to delete dataset from {len(failures)} cache location

Error message

Failed to delete dataset from {len(failures)} cache location(s). Some files may remain.

What it means

Raised as HTTP 500 after a dataset cache-deletion pass collected one or more per-location failures. The endpoint walks multiple cache locations (HF hub cache revision deletes, processed-dataset roots, app-processed cache) and accumulates failures; if any location failed, it reports how many failed and warns that files may remain on disk. It is a partial-failure error: some locations may already have been deleted.

Source

Thrown at studio/backend/hub/services/datasets/cache_inventory.py:639

        }

    processed_deleted, processed_failures = _delete_processed_dataset_cache(
        repo_id, only_roots = processed_roots
    )
    failures.extend(processed_failures)
    delete_app_cache = not cache_path or app_entry is not None or target_root is not None
    app_hub_cache = app_entry.hub_cache if app_entry is not None else target_root
    app_deleted, app_failures = (
        _delete_app_processed_dataset_cache(
            repo_id,
            hub_cache = app_hub_cache,
        )
        if delete_app_cache
        else (False, [])
    )
    failures.extend(app_failures)
    if failures:
        raise HTTPException(
            status_code = 500,
            detail = (
                f"Failed to delete dataset from {len(failures)} cache "
                "location(s). Some files may remain."
            ),
        )

    # ``scan_cache_dir()`` skips blob-only/corrupt repos the revision delete can't touch, yet the
    # fallback scanner shows them, so purge the whole dir. Hub cache targets only.
    cache_purged = partial_purged = state_purged = False
    if target_root is not None:
        cache_purged = purge_repo_cache_dirs("dataset", repo_id, root = target_root)
        partial_purged = purge_partial_repo("dataset", repo_id, root = target_root)
        state_purged = (
            download_manifest.purge_all_state_for_repo("dataset", repo_id, hub_cache = target_root)
            > 0
        )
    if not (

View on GitHub (pinned to 203007d190)

Solutions

  1. Check the server logs for the per-location failure messages appended to `failures` before the raise; they name the exact paths and OS errors.
  2. Fix filesystem permissions on the reported cache roots (chown/chmod) so the backend process owns the snapshot/refs/blobs dirs.
  3. Stop concurrent downloads or Studio jobs touching the same repo_id, then retry the delete request.
  4. If the location is externally managed (read-only mount), delete it manually with rm -rf on the reported path and re-run the endpoint to confirm a clean 200.

Example fix

# before: cache dirs owned by root after a docker run as root
# ls -lan ~/.cache/huggingface/hub/datasets__foo  -> uid 0
sudo chown -R $(id -u):$(id -g) ~/.cache/huggingface/hub
# after: retry DELETE /datasets/cache {"repo_id": "foo"} -> 200 {"status": "deleted"}
Defensive patterns

Strategy: retry

Validate before calling

# Before deleting, confirm writability of the cache roots you expect to touch
import os
from pathlib import Path

def cache_roots_writable(roots: list[Path]) -> list[str]:
    problems = []
    for r in roots:
        if r.exists() and not os.access(r, os.W_OK | os.X_OK):
            problems.append(str(r))
    return problems

Try / catch

try:
    delete_dataset_cache(client, repo_id)
except HTTPStatusError as e:
    if e.response.status_code == 500 and "cache location" in e.response.text:
        # partial failure: read server logs for per-path failures, fix perms, retry once
        fix_permissions_from_logs(); retry_once()
    else:
        raise

Prevention

When it happens

Trigger: Calling the delete-dataset-cache endpoint for a repo_id whose cache directories live under a root the process cannot write/delete (permission denied), blobs locked by another process on Windows, an NFS/SID-mapped mount, or a path removed mid-walk between scan and delete.

Common situations: Cache dirs created by root or a different user during earlier runs; read-only mounts; concurrent downloads writing into the same snapshot dir while deletion runs; antivirus/IDE holding file handles open.

Related errors


AI-assisted analysis of unslothai/unsloth@203007d190 (2026-08-15). Data as JSON: /api/errors/bdb34da205c6c4b2. Report an issue: GitHub.