# Spaces Persistent Storage Upgrade Not Accessible

**URL:** <https://discuss.huggingface.co/t/spaces-persistent-storage-upgrade-not-accessible/171226>\
**Category:** Spaces\
**Created:** [December 6, 2025, 6:23pm UTC](https://discuss.huggingface.co/t/spaces-persistent-storage-upgrade-not-accessible/171226 "2025-12-06T18:23:43Z")\
**Posts on this page:** 19\
**Page:** 1

<div class="post-metadata">

**Author:** ![littlewoko](https://sea2.discourse-cdn.com/hellohellohello/user_avatar/discuss.huggingface.co/littlewoko/32/56330_2.png) [@littlewoko](https://discuss.huggingface.co/u/littlewoko)\
**Post date:** [December 6, 2025, 6:23pm UTC](https://discuss.huggingface.co/t/spaces-persistent-storage-upgrade-not-accessible/171226/1 "2025-12-06T18:23:43Z")

</div>

Hi,

I am working on a small space for my Master’s project which will log and store session data during usage. I was storing this in /tmp and recently moved to /data. On the free tier this is still ephemeral, which I expected, however I have no option to upgrade to a paid tier to activate the persistent storage.

I have linked a payment method, and I have searched all settings panels (space, account, etc., ) to no luck. I was hoping to activate the small storage tier and begin running my experiments with users this week.

If anyone could help me out in understanding why I don’t have the option, and what (if anything) I can do to get this working i’d be very grateful!

Thank you!

---

<div class="post-metadata">

**Author:** ![John6666](https://sea2.discourse-cdn.com/hellohellohello/user_avatar/discuss.huggingface.co/john6666/32/27664_2.png) [@John6666](https://discuss.huggingface.co/u/John6666)\
**Post date:** [December 6, 2025, 11:26pm UTC](https://discuss.huggingface.co/t/spaces-persistent-storage-upgrade-not-accessible/171226/2 "2025-12-06T23:26:43Z")

</div>

There seems to be a valid case where the Persistent Storage option doesn’t appear for Enterprise orgs…?

Otherwise, it’s likely a Hugging Face bug or browser malfunction, so contact Hugging Face via email.

* * *

You are not missing a hidden toggle.  
Given Hugging Face’s own docs, the option to buy persistent storage **should** appear in your Space’s Settings. If it doesn’t, that is almost certainly a Hugging Face–side issue (account / org / region / feature flag), not something you can fix in code or by clicking around more. ([Hugging Face](https://huggingface.co/docs/hub/spaces-storage "Disk usage on Spaces"))

Below is the concrete picture, from first principles.

* * *

## 1. Background: how storage in Spaces actually works

There are three different “storages” involved. Mixing them up is what usually causes confusion.

### 1.1. Runtime disk (what `/tmp` and `/data` sit on)

- Every Space gets a **runtime filesystem** when it runs.
- On free CPU hardware that is **50 GB and ephemeral** : when the Space restarts or is stopped, the contents are wiped. ([Hugging Face](https://huggingface.co/docs/hub/en/spaces-overview "Spaces Overview"))
- By default, everything under `/` (including `/tmp`) lives on that ephemeral disk.

Hugging Face’s own “Disk usage on Spaces” page states that this default disk is ephemeral and that if you need longer-term data you **must either** subscribe to persistent storage or use a dataset as a datastore. ([Hugging Face](https://huggingface.co/docs/hub/spaces-storage "Disk usage on Spaces"))

So your observation:

- `/tmp` → data gone on restart
- `/data` on free tier → also gone on restart

is exactly what the docs say should happen when you have **no paid storage attached**.

### 1.2. Persistent storage

Persistent storage is a **separate paid volume** that you attach to a Space.

Key properties from the docs:

- You “upgrade your Space to have access to persistent disk space from the Settings tab.” ([Hugging Face](https://huggingface.co/docs/hub/spaces-storage "Disk usage on Spaces"))

- It is mounted into the container at **`/data`**. You read/write to it like a normal disk. ([Hugging Face](https://huggingface.co/docs/hub/spaces-storage "Disk usage on Spaces"))

- Tiers and pricing (per Space):

So under normal circumstances, once you buy “Small”, `/data` is on that paid volume and survives restarts. If you never buy it, `/data` is just another path on the ephemeral disk.

### 1.3. Hub repos and datasets (a separate persistence channel)

The same docs explicitly say that if you need data that outlives the Space itself you can also use a **dataset repository** as a data store. ([Hugging Face](https://huggingface.co/docs/hub/spaces-storage "Disk usage on Spaces"))

That option is important for you, because it does not depend on the persistent-storage feature working.

* * *

## 2. What you _should_ see in the UI

Multiple official docs and third-party guides assume the same user interface:

1. Open your Space in the browser.

2. Go to the **Settings** tab of that Space (not your global account settings).

3. Somewhere on that page, you see:

The JupyterLab-on-Spaces guide states this very plainly:

> To set up persistent storage on the Space, you go to the Settings page of your Space and choose one of the options: `small`, `medium` and `large`. ([Hugging Face](https://huggingface.co/docs/hub/spaces-sdks-docker-jupyter "JupyterLab on Spaces"))

The general “Disk usage on Spaces” doc also says:

> You can upgrade your Space to have access to persistent disk space from the **Settings tab**. ([Hugging Face](https://huggingface.co/docs/hub/spaces-storage "Disk usage on Spaces"))

And the Spaces Overview page shows storage tiers (Ephemeral, Small, Medium, Large) and tells you to **click Settings and select your preferred hardware environment** , including persistent storage. ([Hugging Face](https://huggingface.co/docs/hub/en/spaces-overview "Spaces Overview"))

So under normal conditions, after you have a card on file, **the Storage card exists** , and you pick a tier there.

In your case, that entire upgrade control is missing despite:

- You having a working Space.
- You understanding that `/data` is ephemeral on free tier.
- You having added a payment method. ([Hugging Face Forums](https://discuss.huggingface.co/t/spaces-persistent-storage-upgrade-not-accessible/171226 "Spaces Persistent Storage Upgrade Not Accessible - Spaces - Hugging Face Forums"))

That is not described in any public docs as expected behavior.

* * *

## 3. Why the upgrade option can be missing

There is no public page that says “persistent storage only exists for specific user plans” or “only for certain Spaces.” Instead, the docs treat it as a normal paid add-on you can always choose in Settings or via API. ([Hugging Face](https://huggingface.co/docs/hub/spaces-storage "Disk usage on Spaces"))

Given that, your situation almost certainly comes from **how your Space or account is configured on Hugging Face’s side** , not from anything you did.

### 3.1. Region / advanced-compute constraints (especially orgs)

For Enterprise orgs, Hugging Face supports **storage regions** (US, EU, etc.) and explicitly says that:

> Available hardware configurations vary by region, and some features may not be available in all regions, **like persistent storage associated to a Space**. ([Hugging Face](https://huggingface.co/docs/hub/storage-regions "Storage Regions on the Hub"))

If your Space is:

- Under an **organization** that uses a non-default region, or
- Under some internal “advanced compute” configuration,

then persistent storage may be disabled for that region, and the UI will simply not show it.

### 3.2. Owner vs organization billing

Billing for Spaces upgrades (hardware and storage) is tied to the **owner account / organization** , not to each individual contributor.

- The Spaces overview and “Manage your Space” docs both say upgraded hardware and storage are requestable when you have a payment method and use `space_storage="small"` or `request_space_storage`. ([Hugging Face](https://huggingface.co/docs/hub/en/spaces-overview "Spaces Overview"))
- Those API calls are sent on behalf of whichever account or org owns the Space.

If:

- The Space is under an **org** ,
- You added a card only to your **personal** billing settings, and
- The org has no payment method registered,

it is plausible that the UI hides storage upgrades for that Space because the **owner** (the org) has no valid billing setup, even though you personally do.

There is no explicit doc line confirming “we hide the storage card when billing is missing,” but this pattern is consistent with how hardware upgrades require card or grant on the owner. ([Hugging Face](https://huggingface.co/docs/huggingface_hub/en/guides/manage-spaces "Manage your Space"))

### 3.3. Feature flag or UI bug

HF clearly runs a lot of things via backend flags:

- For example, the Hub docs mention features “not currently exposed to end users” that HF can toggle if you email `website@huggingface.co`. ([Hugging Face](https://huggingface.co/mishig/llms-txt/raw/main/hub.txt "raw"))
- Persistent storage itself is configurable via API (`request_space_storage`) with a `SpaceStorage` enum (small/medium/large). ([Hugging Face](https://huggingface.co/docs/huggingface_hub/en/guides/manage-spaces "Manage your Space"))

If your account or Space did not get the correct flag, the Settings UI will not render the storage selector even though the docs assume it exists. That matches exactly what you see.

Community answers on other persistent-storage problems often end with “contact HF support ([website@huggingface.co](mailto:website@huggingface.co), [billing@huggingface.co](mailto:billing@huggingface.co)) for paid storage issues,” which is another hint that some parts of this system are not self-service. ([Hugging Face Forums](https://discuss.huggingface.co/t/space-stuck-at-running-nothing-works-cant-access-paid-storage-who-to-contact/164726 "Nothing Works / Cant Access Paid Storage / Who to Contact?"))

* * *

## 4. Concrete checks you can do yourself

These checks will not fix a backend bug, but they help narrow down the cause before you email support.

### 4.1. Confirm you’re in the Space Settings, not only account settings

From the docs’ perspective, the flow is:

1. Open **the Space page** (e.g., `https://huggingface.co/spaces/you/your-space`).

2. Click the **Settings** tab on that Space, next to “App / Files / Community”.

3. Scroll; there should be:

You already looked, but it is important: if the _entire_ storage card is missing, that’s the problem. Not a “wrong place” issue.

### 4.2. Check whether the Space is owned by you or by an org

On the Space page, look at the identifier:

- `your-username/space-name` → personal Space.
- `org-name/space-name` → organization-owned Space.

If it is under an organization:

- Ask an **org admin** to open that Space’s Settings and see whether they see a storage section.
- Confirm whether the org has a payment method in its own billing settings. ([Hugging Face](https://huggingface.co/docs/hub/en/billing "Billing"))

If the org has no billing configured, that increases the odds that upgrades are hidden.

### 4.3. Create a tiny test Space under your personal account

Create a bare-bones Gradio Space under your personal user (not the org), then:

- During creation, some templates show a storage selector (Ephemeral vs persistent) as part of the “Create Space” dialog. ([Label Studio](https://labelstud.io/blog/kickstart-your-label-studio-annotation-project-on-hugging-face-spaces/ "Kickstart your Label Studio Annotation Project on Hugging ..."))
- After creation, open its Settings and check if a Storage section appears.

Outcomes:

- If the test Space **does** show storage options but your MSc Space does not, the problem is specific to that existing repo (a broken flag or older configuration).
- If **neither** Space shows storage options, this is more likely account-level (or region-level) gating.

### 4.4. Optional: try the Python API from outside Spaces

If you are comfortable with Python, you can directly call the public API to request storage and see what error you get:

```python
from huggingface_hub import HfApi, SpaceStorage

api = HfApi(token="hf_...") # use a user token with write access

repo_id = "OWNER/SPACE_NAME" # e.g. "littlewoko/my-msc-space"

api.request_space_storage(repo_id=repo_id, storage=SpaceStorage.SMALL)

```

This is the documented way to add persistent storage programmatically. ([Hugging Face](https://huggingface.co/docs/huggingface_hub/en/guides/manage-spaces "Manage your Space"))

- If this returns something like “feature not available” or `403`, that suggests a **permission / plan / region** gate.
- If it `200`s but the UI still shows no storage card, that suggests a **pure UI bug**.

Either way, the response is something you can attach to your support message.

* * *

## 5. How to get it fixed: contacting Hugging Face

For anything involving paid features, the official path is via Hugging Face support:

- **Billing and paid features:** `billing@huggingface.co` (address given in the official billing docs and Hub overview). ([Hugging Face](https://huggingface.co/docs/hub/en/billing "Billing"))
- **General site / feature toggles:** `website@huggingface.co` is often mentioned in Hub docs as the contact point for features that are not user-exposed yet. ([Hugging Face](https://huggingface.co/mishig/llms-txt/raw/main/hub.txt "raw"))

When you email them, include:

- A link to the affected Space.

- A screenshot of that Space’s Settings tab, showing that there is no Storage / persistent storage section.

- A short description:

- Optionally: the status code and message from `request_space_storage` if you tried the API.

From public documentation, there is no setting you can change to “un-hide” this; HF staff need to check the Space’s region, owner, and internal flags.

* * *

## 6. What to do for your MSc experiments _right now_

You want to start experiments this week. You do not need to wait for HF to fix persistent storage to get reliable logging.

The safe design is:

> Treat the Space as stateless compute and UI.  
> Treat persistence as remote: a dataset repo or external DB.

### 6.1. Using a Hub dataset as your “database”

The storage docs explicitly recommend using a **dataset repository** as a durable store when you need data that outlives the Space. ([Hugging Face](https://huggingface.co/docs/hub/spaces-storage "Disk usage on Spaces"))

Pattern:

1. Create a dataset repo, for example `your-username/msc-session-logs`.
2. Create an HF token with write access.
3. In the Space, set that token as a **secret** (Settings → Secrets). ([Hugging Face](https://huggingface.co/docs/hub/en/spaces-overview "Spaces Overview"))
4. When a user finishes a session, append a JSON or CSV record to the dataset via `huggingface_hub`.

Very simple example:

```python
import json, uuid, datetime as dt
from huggingface_hub import HfApi

DATASET_ID = "your-username/msc-session-logs" # dataset repo
api = HfApi(token=os.environ["HF_TOKEN"]) # set HF_TOKEN as a Space secret

def log_session(data: dict):
    session_id = str(uuid.uuid4())
    ts = dt.datetime.utcnow().isoformat()
    path_in_repo = f"logs/{ts}_{session_id}.json"

    api.upload_file(
        repo_id=DATASET_ID,
        repo_type="dataset",
        path_in_repo=path_in_repo,
        path_or_fileobj=json.dumps(data).encode("utf-8"),
    )

```

This gives you:

- One JSON file per session under `logs/`, persisted on the Hub.
- Data independent of the Space’s runtime disk.
- Easy offline analysis: you can clone the dataset and run your MSc analysis locally.

This is exactly the type of pattern the docs suggest in their “Dataset storage” section. ([Hugging Face](https://huggingface.co/docs/hub/spaces-storage "Disk usage on Spaces"))

### 6.2. External database (if you prefer “classic” infra)

You can also use a managed DB (Postgres, Supabase, Firebase, etc.) and send logs from the Space over HTTPS. This is the same pattern many teams follow when using Spaces as a front end and keeping state in their own infra. ([Hugging Face](https://huggingface.co/docs/huggingface_hub/en/guides/manage-spaces "Manage your Space"))

Tradeoffs:

- More moving parts and credentials.
- More control and potentially easier integration with university data systems.

### 6.3. Where persistent storage fits if/when it works

If HF later fixes your persistent storage UI:

- Use `/data` mainly for **caches** and **local working files** (e.g. `HF_HOME=/data/.huggingface` so models and datasets do not re-download every time). ([Hugging Face](https://huggingface.co/docs/hub/spaces-storage "Disk usage on Spaces"))
- Keep the authoritative research data (logs, labels, outputs used in the thesis) in a **dataset or DB** , which is easier to clone, back up, and reference in your write-up. ([Hugging Face](https://huggingface.co/docs/hub/spaces-storage "Disk usage on Spaces"))

That way, your experiment does not depend on the fate of a single Space’s attached disk.

* * *

## 7. Summarised next steps

- **You are not doing anything wrong.** Docs say the persistent storage selector should appear in your Space’s Settings; if it is missing, that is inconsistent with the documented behavior. ([Hugging Face](https://huggingface.co/docs/hub/spaces-storage "Disk usage on Spaces"))
- **Check basics:** Confirm the Space owner (you vs org), verify billing for that owner, and test with a fresh personal Space. This distinguishes account-level, org-level, and repo-level issues. ([Hugging Face](https://huggingface.co/docs/hub/en/spaces-overview "Spaces Overview"))
- **Optionally probe via API:** Call `request_space_storage` with `SpaceStorage.SMALL` and see whether you get “not allowed” vs success; include that in your support message. ([Hugging Face](https://huggingface.co/docs/huggingface_hub/en/guides/manage-spaces "Manage your Space"))
- **Escalate to Hugging Face:** Email `billing@huggingface.co` (and if you like, `website@huggingface.co`) with Space link, screenshots, and a short description that the persistent storage UI is missing despite the docs. ([Hugging Face](https://huggingface.co/docs/hub/en/billing "Billing"))
- **For your MSc this week:** Implement logging to a Hub dataset or external DB now, and treat persistent storage as an optional future optimization for speed/caching rather than the primary data store. ([Hugging Face](https://huggingface.co/docs/hub/spaces-storage "Disk usage on Spaces"))

This keeps your experiment robust and unblocked, regardless of how quickly HF resolves the missing upgrade option.

---

<div class="post-metadata">

**Author:** ![littlewoko](https://sea2.discourse-cdn.com/hellohellohello/user_avatar/discuss.huggingface.co/littlewoko/32/56330_2.png) [@littlewoko](https://discuss.huggingface.co/u/littlewoko)\
**Post date:** [December 7, 2025, 3:09pm UTC](https://discuss.huggingface.co/t/spaces-persistent-storage-upgrade-not-accessible/171226/3 "2025-12-07T15:09:36Z")

</div>

Amazing, thank you! Couldn’t have asked for a more robust response. I’ll try out getting the upgrade working programmatically, but regardless you’ve given me plenty of direction so thanks again! I’ll ping hugging face an email with details so that they’re aware of the bug/ issue.

---

<div class="post-metadata">

**Author:** ![littlewoko](https://sea2.discourse-cdn.com/hellohellohello/user_avatar/discuss.huggingface.co/littlewoko/32/56330_2.png) [@littlewoko](https://discuss.huggingface.co/u/littlewoko)\
**Post date:** [December 7, 2025, 3:19pm UTC](https://discuss.huggingface.co/t/spaces-persistent-storage-upgrade-not-accessible/171226/4 "2025-12-07T15:19:55Z")

</div>

Update: the programmatic update worked and I can see that the small persistent storage tier is now visible and selected. Within the UI I still have no option for any of the other storage tiers, but at least I’m on the one I need for now! Definitely a strange little UI bug.

Thanks so much again for getting on this so quickly @John6666 , you’ve been incredibly helpful.

---

<div class="post-metadata">

**Author:** ![rwieczor84](https://sea2.discourse-cdn.com/hellohellohello/user_avatar/discuss.huggingface.co/rwieczor84/32/56349_2.png) [@rwieczor84](https://discuss.huggingface.co/u/rwieczor84)\
**Post date:** [December 7, 2025, 3:25pm UTC](https://discuss.huggingface.co/t/spaces-persistent-storage-upgrade-not-accessible/171226/5 "2025-12-07T15:25:55Z")

</div>

Hi, I’m also having trouble with persistence storage. I can’t even enable the small version because it’s not available. I’ve checked on two accounts, updated payment methods, and nothing—I don’t have persistence storage.

What can I do?

---

<div class="post-metadata">

**Author:** ![littlewoko](https://sea2.discourse-cdn.com/hellohellohello/user_avatar/discuss.huggingface.co/littlewoko/32/56330_2.png) [@littlewoko](https://discuss.huggingface.co/u/littlewoko)\
**Post date:** [December 7, 2025, 3:38pm UTC](https://discuss.huggingface.co/t/spaces-persistent-storage-upgrade-not-accessible/171226/6 "2025-12-07T15:38:48Z")

</div>

> [@John6666](#):
>
> ```auto
> from huggingface_hub import HfApi, SpaceStorage
> 
> api = HfApi(token="hf_...") # use a user token with write access
> 
> repo_id = "OWNER/SPACE_NAME" # e.g. "littlewoko/my-msc-space"
> 
> api.request_space_storage(repo_id=repo_id, storage=SpaceStorage.SMALL)
> 
> ```

Running this script did the trick for me (fill in with your specific details).

```auto
from huggingface_hub import HfApi, SpaceStorage

api = HfApi(token="hf_...") # use a user token with write access

repo_id = "OWNER/SPACE_NAME" # e.g. "littlewoko/my-msc-space"

api.request_space_storage(repo_id=repo_id, storage=SpaceStorage.SMALL)

```

Otherwise, @John6666 ‘s response had some comprehensive steps to persist what you need otherwise. Hope you can get it working! Maybe it’s a more widespread issue that has started recently.

---

<div class="post-metadata">

**Author:** ![rwieczor84](https://sea2.discourse-cdn.com/hellohellohello/user_avatar/discuss.huggingface.co/rwieczor84/32/56349_2.png) [@rwieczor84](https://discuss.huggingface.co/u/rwieczor84)\
**Post date:** [December 7, 2025, 4:56pm UTC](https://discuss.huggingface.co/t/spaces-persistent-storage-upgrade-not-accessible/171226/7 "2025-12-07T16:56:45Z")

</div>

Thanks! That worked for me 🙂

---

<div class="post-metadata">

**Author:** ![Hanzo03](https://sea2.discourse-cdn.com/hellohellohello/user_avatar/discuss.huggingface.co/hanzo03/32/57228_2.png) [@Hanzo03](https://discuss.huggingface.co/u/Hanzo03)\
**Post date:** [January 12, 2026, 9:22am UTC](https://discuss.huggingface.co/t/spaces-persistent-storage-upgrade-not-accessible/171226/8 "2026-01-12T09:22:51Z")

</div>

this worked for me too,  
thanks for the advice

---

<div class="post-metadata">

**Author:** ![Minimartzz](https://avatars.discourse-cdn.com/v4/letter/m/8491ac/32.png) [@Minimartzz](https://discuss.huggingface.co/u/Minimartzz)\
**Post date:** [January 14, 2026, 11:27am UTC](https://discuss.huggingface.co/t/spaces-persistent-storage-upgrade-not-accessible/171226/9 "2026-01-14T11:27:58Z")

</div>

Hello,

I just wanted to check if this is a related issue. I am completely missing the Storage/ Persistent Storage option within my Space settings, and I only see the Storage Usage (screenshot below). I am running a docker version of Argilla but can only see the Space Hardware options in the Space settings page.

I did not try enabling it programmatically, but wanted to check if there is some setup that I’m doing wrongly with my Spaces that doesn’t allow me to see it.

What I’m seeing under my Space settings

 ![image](https://us1.discourse-cdn.com/hellohellohello/original/3X/5/b/5b32775374453c8712b4448df312d7e6a0366407.png)

---

<div class="post-metadata">

**Author:** ![John6666](https://sea2.discourse-cdn.com/hellohellohello/user_avatar/discuss.huggingface.co/john6666/32/27664_2.png) [@John6666](https://discuss.huggingface.co/u/John6666)\
**Post date:** [January 14, 2026, 10:06pm UTC](https://discuss.huggingface.co/t/spaces-persistent-storage-upgrade-not-accessible/171226/10 "2026-01-14T22:06:02Z")

</div>

@meganariley Paid option issue?

---

<div class="post-metadata">

**Author:** ![meganariley](https://sea2.discourse-cdn.com/hellohellohello/user_avatar/discuss.huggingface.co/meganariley/32/56966_2.png) [@meganariley](https://discuss.huggingface.co/u/meganariley)\
**Post date:** [January 14, 2026, 10:40pm UTC](https://discuss.huggingface.co/t/spaces-persistent-storage-upgrade-not-accessible/171226/11 "2026-01-14T22:40:17Z")

</div>

Hi @Minimartzz There’s a similar discussion [here](https://discuss.huggingface.co/t/persistent-storage-not-visible-in-org-space-after-payment-info-added/172396/3).

Persistent storage isn’t available for new Spaces, but you can use [Dataset Storage](https://huggingface.co/docs/hub/en/spaces-storage#dataset-storage) instead.

---

<div class="post-metadata">

**Author:** ![Minimartzz](https://avatars.discourse-cdn.com/v4/letter/m/8491ac/32.png) [@Minimartzz](https://discuss.huggingface.co/u/Minimartzz)\
**Post date:** [January 15, 2026, 8:40am UTC](https://discuss.huggingface.co/t/spaces-persistent-storage-upgrade-not-accessible/171226/12 "2026-01-15T08:40:30Z")

</div>

Hi @meganariley @John6666 Thanks for the info, I’ll checkout those links!

---

<div class="post-metadata">

**Author:** ![Thytu](https://sea2.discourse-cdn.com/hellohellohello/user_avatar/discuss.huggingface.co/thytu/32/57554_2.png) [@Thytu](https://discuss.huggingface.co/u/Thytu)\
**Post date:** [January 27, 2026, 3:36pm UTC](https://discuss.huggingface.co/t/spaces-persistent-storage-upgrade-not-accessible/171226/13 "2026-01-27T15:36:20Z")

</div>

Worked thanks

---

<div class="post-metadata">

**Author:** ![karolinaranjo](https://sea2.discourse-cdn.com/hellohellohello/user_avatar/discuss.huggingface.co/karolinaranjo/32/58815_2.png) [@karolinaranjo](https://discuss.huggingface.co/u/karolinaranjo)\
**Post date:** [March 27, 2026, 12:59am UTC](https://discuss.huggingface.co/t/spaces-persistent-storage-upgrade-not-accessible/171226/14 "2026-03-27T00:59:54Z")

</div>

# Posting this as a follow-up for others facing the same issue.

We ran into the same problem with an Argilla Space — after the persistent storage upgrade, the Space became inaccessible and we lost the dataset.  
The core issue seemed to be a disconnect: the small storage tier we had originally configured in Argilla is no longer available, leaving the Space in a broken state with no clear migration path.

We tried three approaches, none of which fully resolved the problem:

### 1. Requesting the storage upgrade programmatically via the API

Following the steps from this forum, we called request\_space\_storage() with a write-access token:

```auto
load_dotenv(Path.cwd() / “.env”) HF_STORAGE = os.environ.get(“HF_STORAGE”)

api = HfApi(token=HF_STORAGE)repo_id = “your-username/your-space-name”

api.request_space_storage(repo_id=repo_id, storage=SpaceStorage.SMALL)print(f"Storage requested for {repo_id}")

```

Result:

```auto
HfHubHTTPError: Client error ‘404 Not Found’ for url‘https://huggingface.co/api/spaces/your-username/your-space-name/storage’

```

The endpoint returns 404 — the SMALL storage tier appears to no longer be available for this Space. The upgrade option is also absent from the Space  
Settings UI.

### 2.Uploading the dataset to a Hub dataset repository

We followed the standard pattern — created a dataset repo, set an HF token with write access as a Space secret, and pushed the data via huggingface\_hub. The data transferred fine, but this approach does not reproduce the Argilla-specific configuration: dataset settings, annotation guidelines, label schemas, and field definitions set up in the Argilla UI are not exported with the data. You get the raw records but lose the annotation workspace entirely.

### 3.Self-hosting Argilla on an external VPS (Vultr)

We deployed Argilla on a Vultr instance (4 GB RAM / 128 GB storage, Ubuntu) using the official Argilla Docker Compose setup:

1. Provision an Ubuntu instance on Vultr
2. Install Docker via the official Docker apt repository: [https://docs.argilla.io/latest/getting\_started/how-to-deploy-argilla-with-docker/](https://docs.argilla.io/latest/getting_started/how-to-deploy-argilla-with-docker/)
3. Download the Argilla docker-compose.yaml from argilla-io/argilla on GitHub
4. Edit credentials in the compose file
5. Start with docker compose up -d and open the Argilla port via iptables

This worked initially — the instance runs at a custom server IP with no dependency on HF persistent storage. However, data uploaded to Argilla on the VPS is also lost when the server is reset, so this does not fully solve the durability problem either.

We are still looking for a reliable solution. Has anyone found a way to either recover access to the original persistent storage tier, or set up a durable Argilla deployment that survives resets?

---

<div class="post-metadata">

**Author:** ![John6666](https://sea2.discourse-cdn.com/hellohellohello/user_avatar/discuss.huggingface.co/john6666/32/27664_2.png) [@John6666](https://discuss.huggingface.co/u/John6666)\
**Post date:** [March 27, 2026, 4:00am UTC](https://discuss.huggingface.co/t/spaces-persistent-storage-upgrade-not-accessible/171226/15 "2026-03-27T04:00:51Z")

</div>

I’m not very familiar with Argilla, but it seems that exporting and importing data at the Argilla data unit level—rather than on a file-by-file basis—is important.

I don’t know the background behind the sudden discontinuation of Persistent Storage, but it certainly seems to have been discontinued…

* * *

For your situation, the best practice is to **treat the Space as disposable** and move durability somewhere else. The current Hugging Face docs say persistent storage is no longer available, while other Hugging Face docs and API references still describe the older storage flow. That means chasing the old `small` tier is not a reliable operating plan anymore. ([Hugging Face](https://huggingface.co/docs/hub/spaces-config-reference "Spaces Configuration Reference"))

## The core rule

**Do not let a Hugging Face Space be the only copy of Argilla state.**  
Use the Space for UI and compute. Keep durable data outside it. That matches Hugging Face’s newer storage direction, where repos are Git-based and buckets are mutable object storage. ([Hugging Face](https://huggingface.co/docs/hub/storage-buckets "Storage Buckets · Hugging Face"))

## Best practices for you

### 1. Stop trying to recover the old storage tier as your main plan

You can still ask support, but I would treat that as a low-probability rescue path, not as the design. The docs currently say the persistent-storage setting is ignored, even though other docs still expose storage-management methods. That is a documentation and product-state mismatch, not a stable workflow. ([Hugging Face](https://huggingface.co/docs/hub/spaces-config-reference "Spaces Configuration Reference"))

### 2. Back up at the **Argilla dataset layer** , not just the file-upload layer

Your backup unit should be the **Argilla dataset** , not just “files pushed to the Hub.” Argilla’s docs say a complete dataset includes the configuration in `rg.Settings` plus the records, and their `to_hub` / `from_hub` and `to_disk` / `from_disk` flows are specifically for exporting and restoring that full dataset. The `to_disk` reference says the export contains the dataset model, settings, and records as JSON files. ([Argilla Docs](https://docs.argilla.io/v2.3/how_to_guides/import_export/ "Import and export datasets - Argilla Docs"))

### 3. Keep **two independent backups** at all times

For every important milestone, keep:

- one **Hub dataset repo** copy for versioned external backup,
- one **local disk** copy outside the Space or VPS.  
This is the safest pattern because it protects you from both Space failure and single-host failure, and it uses the Argilla-supported export flows rather than ad hoc copying. ([Argilla Docs](https://docs.argilla.io/v2.3/how_to_guides/import_export/ "Import and export datasets - Argilla Docs"))

### 4. Use the right Hugging Face storage for the right job

Use a **dataset repo** when you want versioned, inspectable snapshots of Argilla datasets. Use a **Storage Bucket** for mutable artifacts such as logs, uploaded files, exports in progress, checkpoints, or other large files that change often. Hugging Face’s docs explicitly distinguish repos from buckets this way. ([Hugging Face](https://huggingface.co/docs/hub/storage-buckets "Storage Buckets · Hugging Face"))

### 5. For any serious Argilla deployment, use a real stateful stack

Argilla is not just one container with a folder. Its docs describe a relational database layer, a search layer, and related server configuration, and the official Compose example includes **Argilla, PostgreSQL, Elasticsearch, Redis, and named volumes**. That is the shape you should think in when the data matters. ([Argilla Docs](https://docs.argilla.io/latest/reference/argilla-server/configuration/ "Server configuration"))

### 6. Separate **container persistence** from **host persistence**

Docker volumes persist beyond the life of an individual container. That protects you from `docker compose down` / `up` cycles and container recreation. It does **not** protect you from losing the host itself, rebuilding the VM, or destroying the underlying disk. Docker’s own docs are explicit that volumes persist beyond the container lifecycle. ([Docker Documentation](https://docs.docker.com/get-started/docker-concepts/running-containers/persisting-container-data/ "Persisting container data | Docker Docs"))

### 7. On Vultr, add host-level backups intentionally

This is where your VPS attempt likely fell short. Vultr’s docs say automatic backups cover the compute instance’s active file system, but **do not include attached Block Storage volumes**. So a durable Vultr design needs both persistent storage for the live service and a separate backup plan for that storage. ([Vultr Docs](https://docs.vultr.com/products/orchestration/backups "Backups"))

### 8. Test restore, not just backup

A backup is only real if restore works. Argilla’s docs support restoring datasets from the Hub and from disk. So your standard operating procedure should include a restore drill into a fresh workspace or staging instance after major annotation milestones. ([Argilla Docs](https://docs.argilla.io/v2.3/how_to_guides/import_export/ "Import and export datasets - Argilla Docs"))

## What I would do in your place

### Good enough for a short project

Use the Space only as a temporary frontend. After each session or milestone:

1. export the dataset with Argilla’s export methods,
2. push to a Hub dataset repo,
3. also write a local disk export,
4. store large mutable artifacts outside the repo, ideally in a bucket. ([Argilla Docs](https://docs.argilla.io/v2.3/how_to_guides/import_export/ "Import and export datasets - Argilla Docs"))

### Better for an ongoing team workflow

Keep Hugging Face for sharing and snapshots, but move the authoritative runtime off the Space. Run Argilla on a VPS or managed environment with Postgres, Elasticsearch or OpenSearch, Redis, Docker volumes, and host-level backups. That matches Argilla’s documented architecture much better than relying on Space-local state. ([Argilla Docs](https://docs.argilla.io/latest/reference/argilla-server/configuration/ "Server configuration"))

### Best for anything you would be upset to lose

Use **three layers** :

- **live runtime** : self-hosted Argilla with persistent volumes or managed data services,
- **versioned dataset backup** : Argilla `to_hub` to a dataset repo,
- **offline or second-site backup** : Argilla `to_disk` copied off the VM. ([Argilla Docs](https://docs.argilla.io/v2.3/how_to_guides/import_export/ "Import and export datasets - Argilla Docs"))

## What not to do

Do not rely on:

- a Space’s local disk as the source of truth,
- plain file uploads as a substitute for Argilla-native dataset export,
- Docker volumes alone as your whole disaster-recovery plan,
- Vultr backups without checking whether the actual data disk is included. ([Hugging Face](https://huggingface.co/docs/hub/spaces-config-reference "Spaces Configuration Reference"))

## A practical operating checklist

Use this as your default routine:

- **After creating or changing a dataset schema** : export with Argilla, not raw file copy. ([Argilla Docs](https://docs.argilla.io/v2.3/how_to_guides/import_export/ "Import and export datasets - Argilla Docs"))
- **After each annotation milestone** : export to Hub and to disk. ([Argilla Docs](https://docs.argilla.io/v2.3/how_to_guides/import_export/ "Import and export datasets - Argilla Docs"))
- **Before any deployment change or restart-risking change** : snapshot the dataset first. ([Argilla Docs](https://docs.argilla.io/v2.3/how_to_guides/import_export/ "Import and export datasets - Argilla Docs"))
- **For VPS deployments** : confirm named volumes are present for Argilla, Postgres, and Elasticsearch. ([GitHub](https://raw.githubusercontent.com/argilla-io/argilla/main/examples/deployments/docker/docker-compose.yaml "raw.githubusercontent.com"))
- **For VPS durability** : enable snapshots/backups and verify which disks they cover. ([Vultr Docs](https://docs.vultr.com/products/orchestration/backups "Backups"))
- **Once per month** : restore one backup into a clean environment and verify the dataset loads correctly. ([Argilla Docs](https://docs.argilla.io/v2.3/how_to_guides/import_export/ "Import and export datasets - Argilla Docs"))

## My recommendation, plainly

For you, the best practice is:

**Space for convenience. External storage for truth. Self-hosted stack for durability.**

That means:

- do not spend more energy on reviving the old Space persistent-storage path,
- use Argilla-native export/import as your backup primitive,
- keep two backups,
- and move long-lived Argilla state to infrastructure you control. ([Hugging Face](https://huggingface.co/docs/hub/spaces-config-reference "Spaces Configuration Reference"))

---

<div class="post-metadata">

**Author:** ![michellehbn](https://sea2.discourse-cdn.com/hellohellohello/user_avatar/discuss.huggingface.co/michellehbn/32/58964_2.png) [@michellehbn](https://discuss.huggingface.co/u/michellehbn)\
**Post date:** [March 27, 2026, 5:33pm UTC](https://discuss.huggingface.co/t/spaces-persistent-storage-upgrade-not-accessible/171226/16 "2026-03-27T17:33:40Z")

</div>

Hi and thanks for reaching out! We’ve sunset persistent storage for Spaces and now recommend utilising **[HF Mount](https://github.com/huggingface/hf-mount)**, which lets you mount Hub repositories or [Storage Buckets](https://huggingface.co/docs/hub/storage-buckets) directly as volumes. For Spaces, this is currently beta available via the API and UI support is coming soon.

Until this is ready & we publish documentation on using HF Mount for Spaces, you can check out more information on using the already available HF Mount for Jobs: [https://huggingface.co/docs/hub/jobs-configuration#volumes](https://huggingface.co/docs/hub/jobs-configuration#volumes)

We’ll circle back when this is fully available for Spaces! 🚀

---

<div class="post-metadata">

**Author:** ![stadlerb](https://avatars.discourse-cdn.com/v4/letter/s/ecccb3/32.png) [@stadlerb](https://discuss.huggingface.co/u/stadlerb)\
**Post date:** [March 29, 2026, 9:54pm UTC](https://discuss.huggingface.co/t/spaces-persistent-storage-upgrade-not-accessible/171226/17 "2026-03-29T21:54:24Z")

</div>

HF mount sounds great, but can I use it to access the persistent storage that was associated with my Space?

---

<div class="post-metadata">

**Author:** ![John6666](https://sea2.discourse-cdn.com/hellohellohello/user_avatar/discuss.huggingface.co/john6666/32/27664_2.png) [@John6666](https://discuss.huggingface.co/u/John6666)\
**Post date:** [April 1, 2026, 5:18am UTC](https://discuss.huggingface.co/t/spaces-persistent-storage-upgrade-not-accessible/171226/18 "2026-04-01T05:18:12Z")

</div>

I just happened to see this a moment ago:

> **[Storage Buckets for Spaces](https://huggingface.co/changelog/storage-buckets-for-spaces)**
>
> Hugging Face Changelog - Storage Buckets for Spaces

---

<div class="post-metadata">

**Author:** ![dlflannery](https://avatars.discourse-cdn.com/v4/letter/d/7feea3/32.png) [@dlflannery](https://discuss.huggingface.co/u/dlflannery)\
**Post date:** [April 7, 2026, 11:48am UTC](https://discuss.huggingface.co/t/spaces-persistent-storage-upgrade-not-accessible/171226/19 "2026-04-07T11:48:55Z")

</div>

I have two python-gradio spaces that use persistent storage, which I have converted to use buckets.

To access stored files my python code does this:

> from pathlib import Path
> 
> dp = Path(‘/data’)  
> dp.mkdir(exist\_ok=True)  
> dataDir = ‘/data/’
> 
> foo\_path = dataDir + ‘foo.txt’
> 
> with open(foo\_path, ‘rt’) as fp:
> 
> ```auto
> lines = fp.readlines()
> 
> ```
> 
> # etc.

This worked fine under the old presistent storage system. And it worked fine after I set up a mounted bucket in settings with

> /data

as the path. BUT only for several hours. Now I’m getting input/output errors (errno 5) when attempting to access the bucket files. Buckets are public if that makes a difference. And the files I expect to be in the bucket are there.

I’m now doing factory rebuilds on the two spaces and they’re both stuck on restarting.  
Now one of them says runtime error: Scheduling failure: unable to schedule (???)

And other says runtime error: Error: BodyStreamBuffer was aborted (???)

these errors are in the Container log.

I wonder if the mkdir call is a problem because the bucket is already mounted?

Or do I need a completely different method to access the bucket in Python?

EDIT 4/7/2026 4:45PM EST:  
Spaces now working with no changes by me after factory rebuilds, (which I had tried before with no success).