How should I write to bucket from a space

In short, this is maybe platform-side bug or inconsistency… @meganariley @hysts

The simple reading is:

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)

What your results mean

You already confirmed the important part:

• ls /data works
• cat /data/x works
• touch /data/... fails
• mkdir /data/... fails

That means:

• the bucket is mounted
• but your process does not have write permission on that mount

If /data shows:

drwxr-xr-x 2 nobody nogroup ... /data

then 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.

Why this looks wrong

Hugging 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)

But your live result shows two mismatches:

1. Filesystem mismatch

The bucket is visible, but it behaves like a read-only mount for your app because of the owner/group and mode bits.

2. Runtime API mismatch

The 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)

So this is not just one weird thing. It is two weird things at once.

The most likely explanation

The most likely explanation is:

• the feature is new
• your Space has the bucket mounted
• but the mount ownership exposed inside the container does not match the user your app runs as
• and the runtime metadata endpoint is also not reporting volumes correctly in your case

This 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)

So did you do something wrong?

Probably not.

Your evidence points more to a platform-side bug or rollout inconsistency than a user mistake:

• the bucket is attached
• the mount is visible
• read works
• write does not
• runtime metadata is also inconsistent with the docs

One more thing to check

Check your installed huggingface_hub version inside the Space:

import huggingface_hub
print(huggingface_hub.__version__)

If 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)

But even if you upgrade, that probably will not fix the /data write failure by itself, because the filesystem permissions problem is separate.

Practical conclusion

Use this mental model:

Mounted and readable does not mean writable by your app user.

In 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.

Best next move

For 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)

Also include these exact facts in a bug report:

from huggingface_hub import HfApi
import huggingface_hub

print(huggingface_hub.__version__)
api = HfApi()
runtime = api.get_space_runtime("namespace/space")
print(runtime)
print(runtime.raw)
print(hasattr(runtime, "volumes"))

and:

id
ls -ld /data
touch /data/__write_test__
mkdir /data/__dir_test__

That is strong evidence.

In one sentence

Yes, it looks like the mount owner/group is wrong for the Space runtime user, and the missingruntime.volumes field looks like a second bug or rollout inconsistency, not something normal. (Hugging Face)