Unable to access jupyter notebooks on private spaces

Spaces
1

Hi there,

I am trying to run a JupyterLab template using HuggingFace’s Spaces, but as soon as the lab finishes building and starts, the space just gives a 404 error and doesn’t allow me to open the JupyterLab space.

1 Like
2

Hmm… The most common reason for a private space returning a 404 error when it should be accessible is the browser or browser settings. However, if it’s limited to Jupyter spaces, there might be some other cause…

A Hugging Face “404” right after a Space finishes building usually does not mean your repo is missing. In Spaces it often means either:

  • Your browser is not passing the login session into the embedded app (common for private Spaces), so Hugging Face “hides” the app behind a 404.
  • The proxy can’t reach what you started in Docker (wrong port, wrong path, or the app only serves /lab and not /), so the proxy returns a real 404.

Below is the background and the highest-probability fixes.

Background: how Spaces are actually served

A Space has two “layers”:

  1. The Hub page at https://huggingface.co/spaces/<owner>/<space>
  2. The running app hosted on a different domain like https://<space-subdomain>.hf.space

The Hub page shows the app inside an iframe, and the iframe is on a different domain. Hugging Face documents that modern browsers often restrict cookies in this exact “different-domain iframe” setup. (Hugging Face)

For private Spaces, Hugging Face needs cookies/session to prove you are allowed to see the app. If the browser blocks those cookies, the app can appear as “not found” (404) even to you.

The most common cause: third-party cookies blocked (private Space auth fails)

This is the #1 pattern in community reports: private Space works when you allow third-party cookies, fails (404) when you block them.

  • Hugging Face’s own “cookie limitations” doc explains why iframes + different domains cause cookie restrictions. (Hugging Face)
  • A concrete forum fix: add an exception in Chrome to allow third-party cookies for Hugging Face domains (example given: allow [*.]huggingface.co). (Hugging Face Forums)
  • Another report: “public works, private shows 404” even while logged in. (Hugging Face Forums)

What to do (fast)

  1. Try Chrome (no extensions) or Firefox.
  2. Temporarily disable strict tracking prevention and ad blockers.
  3. Allow third-party cookies for Hugging Face (Chrome example is exactly described in the forum thread). (Hugging Face Forums)

Safari and iOS: known pain point for private Spaces

There are repeated reports that private Spaces may not work on Safari/iOS unless you disable cross-site tracking prevention, because cookies must be shared between huggingface.co and *.hf.space. (Hugging Face Forums)

Apple’s own Safari settings description matches this: “Prevent Cross-Site Tracking” limits third-party cookies by default. (Apple Support)

If you are testing on iPhone/iPad Safari, assume this is the cause until proven otherwise. (Hugging Face Forums)

Second common cause: Docker port or path mismatch (proxy hits nothing)

Even if auth is fine, Docker Spaces must expose the correct port and serve the right initial path.

Port: Docker Spaces expect 7860 unless you set app_port

Hugging Face states:

  • Default exposed port is 7860
  • You can change it with app_port in the README YAML. (Hugging Face)

If JupyterLab is running on 8888 (Jupyter default) while the Space proxies 7860, you can get “build succeeded, Space started, but App is 404.”

Check this:

  • README.md YAML includes:

    • sdk: docker
    • app_port: 7860 (or match whatever you run) (Hugging Face)

  • Your startup command binds to 0.0.0.0 and that same port.

Path: Spaces load / unless you set base_path

Docker Spaces load / by default. If your service returns 404 at / (even though it works at some other path), the Space will show 404. The config reference documents base_path, and community debugging threads call out that this is a common reason people see a 404 on the Space homepage. (Hugging Face)

For typical JupyterLab, / should redirect to /lab, so this usually only matters if you changed Jupyter’s base URL or reverse-proxy config.

JupyterLab-specific background: token and storage

Even after the 404 is fixed, two Jupyter-on-Spaces details matter:

  • You can set JUPYTER_TOKEN. If you do not, Hugging Face says it defaults to huggingface, and they recommend setting it especially for public or org Spaces. (Hugging Face)
  • Storage is ephemeral unless you enable persistent storage. The JupyterLab doc says data can be lost on reboot/reset, and persistent storage mounts at /data. (Hugging Face)
    Hugging Face’s storage doc also recommends HF_HOME=/data/.huggingface to persist caches across restarts. (Hugging Face)

This does not cause a 404, but it is the next common “surprise.”

A simple diagnosis flow

Use this quick branching test:

If Public works but Private becomes 404

Treat it as cookie/auth first.

  • Fix: allow third-party cookies, reduce tracking protection, try another browser. (Hugging Face Forums)

If it is 404 even when Public

Treat it as port/path.

  • Fix: confirm app_port and that your process listens on that port. (Hugging Face)
  • Fix: ensure / is served (or set base_path). (Hugging Face)

If it happens mainly on Safari/iOS

Treat it as cross-site tracking prevention.

High-signal references and guides

Summary

  • Private Space + 404 is most often iframe cookie auth failing due to blocked third-party cookies. (Hugging Face)
  • Safari/iOS makes this worse due to cross-site tracking prevention. (Hugging Face Forums)
  • Second major cause is Docker port/path mismatch: app_port (default 7860) and serving / (or base_path). (Hugging Face)
3

Thank you, this fixed it

1 Like
4

This topic was automatically closed 12 hours after the last reply. New replies are no longer allowed.