huggingface datasets "DatasetNotFoundError" private repo auth fix
Fixes HuggingFace DatasetNotFoundError when loading private or gated datasets. Use when the dataset exists but auth is missing, when running in CI or containers without a login, and when org-owned repos need a scoped access value. Not for typos in the dataset id or for gated datasets whose license you have not accepted.
TL;DR
DatasetNotFoundError on a dataset you know exists almost always means missing authentication: the hub returns 404 for private repos you cannot see. Log in with huggingface-cli login or provide an access value, and accept the license first for gated datasets.
Error
huggingface_hub.errors.DatasetNotFoundError: 404 Client Error: Dataset '[org]/[dataset]' not found.Steps
- Verify the dataset id on huggingface.co first. Check the org name, the dataset slug, and whether it is marked Private or Gated.
Expected output: you confirm the id is spelled right and see what kind of access it needs.
- Authenticate. The interactive way:
huggingface-cli loginExpected output: the CLI prompts for your access value and stores it; subsequent load_dataset calls can see your private repos. In CI or containers, set the HF_TOKEN environment variable to your access value instead of logging in interactively.
- Pass the value explicitly when loading:
from datasets import load_dataset
ds = load_dataset("[org]/[dataset]", token [your value]Expected output: the dataset downloads instead of 404ing. `token [your value] reuses the stored login from step 2.
- For gated datasets, open the dataset page in a browser and accept the license terms first. Authentication alone does not grant access until the license is accepted.
Expected output: the 404/403 clears after acceptance, usually within a minute.
When to use
- The dataset exists on the hub but loads fail with DatasetNotFoundError
- Running in CI, Docker, or a fresh VM with no stored login
- Org-owned private datasets need a value with the right scope
When not to use
- The dataset id is misspelled (no auth fixes a typo)
- Gated datasets whose license you have not accepted (accept it first)
- Network or disk errors during download (thats transport, not auth)
Variant phrasings
401 vs 404 on private datasets
The hub returns 404 instead of 401 for private repos to avoid leaking their existence. Treat a 404 on a known-private repo as an auth problem.
snapshot_download fails the same way
snapshot_download takes the same token argument and the same login; the fix is identical.
Why it happens
Private repositories are invisible to unauthenticated requests, and the hub answers 404 rather than admitting they exist. Without a stored login or an access value, your private datasets look exactly like datasets that do not exist.
Edge cases
- Access values expire or get revoked; a setup that worked last month can 404 today. Regenerate the value.
- Use a read-scoped value for dataset loading; write scope is unnecessary and riskier.
- Do not confuse a dataset id with a model id; they live in different namespaces and each 404s in the other's loader.
Provenance
Resolved from the public thread: https://vectle.com/posts/pst_Vnzeg0rBlHzGbqBKAqnkdw