{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreid6okml4dtrqukbuevrpqv5liijbue6xnmzbty4axoy5oncelulyy",
    "uri": "at://did:plc:pgryn3ephfd2xgft23qokfzt/app.bsky.feed.post/3mj4rq3ykwwa2"
  },
  "path": "/t/how-should-i-write-to-bucket-from-a-space/175123#post_4",
  "publishedAt": "2026-04-10T03:46:36.000Z",
  "site": "https://discuss.huggingface.co",
  "tags": [
    "@meganariley",
    "@hysts",
    "Hugging Face",
    "GitHub"
  ],
  "textContent": "In short, this is maybe platform-side bug or inconsistency… @meganariley @hysts\n\n* * *\n\nThe simple reading is:\n\n**the bucket is mounted, but it is mounted with the wrong effective permissions for your app process.** The docs say bucket volumes in Spaces should be mountable at paths like `/data`, and `SpaceRuntime` is documented as having a `volumes` field. The docs also say the `raw` field is the raw server response. (Hugging Face)\n\n## What your results mean\n\nYou already confirmed the important part:\n\n  * `ls /data` works\n  * `cat /data/x` works\n  * `touch /data/...` fails\n  * `mkdir /data/...` fails\n\n\n\nThat means:\n\n  * the bucket **is mounted**\n  * but your process does **not** have write permission on that mount\n\n\n\nIf `/data` shows:\n\n\n    drwxr-xr-x 2 nobody nogroup ... /data\n\n\nthen only the owner has write permission. Group and others can read and enter the directory, but cannot create files. So if your Gradio app is running as a different user, read works and write fails. That matches your symptoms exactly.\n\n## Why this looks wrong\n\nHugging Face’s current docs show bucket volumes mounted into Spaces, including examples that mount a bucket at `/data`. They also document `runtime.volumes` as a field on `SpaceRuntime`. (Hugging Face)\n\nBut your live result shows two mismatches:\n\n### 1. Filesystem mismatch\n\nThe bucket is visible, but it behaves like a read-only mount for your app because of the owner/group and mode bits.\n\n### 2. Runtime API mismatch\n\nThe docs say `runtime.volumes` exists, but your `SpaceRuntime` object has no `volumes` attribute, and your printed `raw` payload does not include `volumes` either. Since the docs define `raw` as the raw server response, that strongly suggests the response you got simply did not include volume metadata. (Hugging Face)\n\nSo this is not just one weird thing. It is **two weird things at once**.\n\n## The most likely explanation\n\nThe most likely explanation is:\n\n  * the feature is new\n  * your Space has the bucket mounted\n  * but the mount ownership exposed inside the container does not match the user your app runs as\n  * and the runtime metadata endpoint is also not reporting volumes correctly in your case\n\n\n\nThis fits the release history. Hugging Face added “Spaces Volumes” in `huggingface_hub` v1.9.0 on April 2, 2026, and then shipped follow-up fixes in v1.9.1 and v1.9.2. (GitHub)\n\n## So did you do something wrong?\n\nProbably not.\n\nYour evidence points more to a **platform-side bug or rollout inconsistency** than a user mistake:\n\n  * the bucket is attached\n  * the mount is visible\n  * read works\n  * write does not\n  * runtime metadata is also inconsistent with the docs\n\n\n\n## One more thing to check\n\nCheck your installed `huggingface_hub` version inside the Space:\n\n\n    import huggingface_hub\n    print(huggingface_hub.__version__)\n\n\nIf it is older than `1.9.0`, that can explain why `runtime.volumes` is missing on the client side, because volume support was added in v1.9.0. (GitHub)\n\nBut even if you upgrade, that probably will **not** fix the `/data` write failure by itself, because the filesystem permissions problem is separate.\n\n## Practical conclusion\n\nUse this mental model:\n\n> **Mounted and readable** does not mean **writable by your app user**.\n\nIn your case, the mount exists, but the owner/group setup appears wrong for the running process. That is why `/data` acts like read-only from your code.\n\n## Best next move\n\nFor now, treat `/data` writes as broken and use the **bucket API** instead of the mounted path for writes. The Spaces docs say secrets become environment variables inside the Space, and bucket/volume support is now part of the Hub tooling. (Hugging Face)\n\nAlso include these exact facts in a bug report:\n\n\n    from huggingface_hub import HfApi\n    import huggingface_hub\n\n    print(huggingface_hub.__version__)\n    api = HfApi()\n    runtime = api.get_space_runtime(\"namespace/space\")\n    print(runtime)\n    print(runtime.raw)\n    print(hasattr(runtime, \"volumes\"))\n\n\nand:\n\n\n    id\n    ls -ld /data\n    touch /data/__write_test__\n    mkdir /data/__dir_test__\n\n\nThat is strong evidence.\n\n## In one sentence\n\n**Yes, it looks like the mount owner/group is wrong for the Space runtime user, and the missing`runtime.volumes` field looks like a second bug or rollout inconsistency, not something normal.** (Hugging Face)",
  "title": "How should I write to bucket from a space"
}