I'm trying to run my own instance of opensearch with a volume attached to it and I'm having permissions issues. On one hand opensearch doesn't allowed to be run as root, on the other hand the volume operates on a directory owned by root. So I decided to take a look at the template. I see that opensearch has created the nodes directory under /usr/share/opensearch/data as it is by default.

The volume is attached to /osdata. and nothing is written to it - no nodes directory. No env variable tells opensearch to write the data to osdata, as far as I can see from the template definition.

I see in the documentation of the template:

Persistent volume for OpenSearch data (/usr/share/opensearch/data)

So, how does the storage to the volume work in the template when the volume mount directory is owned by root but the data is written to /usr/share/opensearch/data?

EDIT: if I understand correctly, the group of osdata should be changed to opensearch and group permissions for /osdata should be changed to rwx, and path.data for the container should be changed to /osdata, in order for opensearch's data to be persisted to the volume. Am I correct?

In the template, OpenSearch writes data to whatever directory is defined in path.data. If your volume is mounted at /osdata, then you need to change path.data to /osdata and make sure the OpenSearch user has write permissions on that directory. If instead you mount the volume directly at /usr/share/opensearch/data, you can keep the default path.data value and no further changes are required.

This template doesn't work out of the box for me. I'm seeing a permissions error related to the mount, and I'm unable to use RAILWAY_RUN_UID=0 because OpenSearch doesn't allow running as root. I did find a similar discussions around permissions that show a workaround that requires wrapping the OpenSearch image in a custom Dockerfile. https://station.railway.com/questions/volume-permissions-3425215f#7pwn

Am I missing something? I see a number of successful deployments on the template page and while the deploy succeeds this template doesn't result in a usable OpenSearch instance.

Hey! Thanks for reporting this.

You’re not missing anything — this is related to Railway volume permissions and how OpenSearch enforces running as a non-root user.

OpenSearch does not allow running as root, so RAILWAY_RUN_UID=0 is not a valid workaround here. When a Railway volume is mounted, the mounted path may not have the ownership OpenSearch expects, which causes the permissions error.

The successful deployments shown on the template page can be a bit misleading here: the deployment itself may complete, but the OpenSearch process can still fail at runtime when persistent storage is attached.

The workaround you found is the correct direction: the template should use a small custom Dockerfile that wraps the official OpenSearch image and fixes the directory permissions before switching back to the non-root OpenSearch user.

I’m going to update the template so it works out of the box with Railway volumes, and I’ll also add a note to the template documentation explaining why this is needed.

Thanks again for catching this and for linking the related discussion.