a month ago
Hello Railway team,
My n8n service is down after a plan change / redeploy because it cannot read/write its mounted volume.
Error in deploy logs:
EACCES: permission denied, open '/home/node/.n8n/config'
Service details:
The volume appears to be owned by root now, while the n8n Docker image runs as user node, so n8n cannot read its existing config/encryption key/database.
Please reset the volume ownership to uid:gid 1000:1000, equivalent to:
chown -R 1000:1000 /home/node/.n8n
Important:
Please preserve all existing data on the volume. This volume contains the n8n config, encryption key, SQLite database, workflows and credentials.
Business impact:
Our production WhatsApp/Instagram automation is currently down because n8n cannot register existing webhooks.
Thank you.
3 Replies
a month ago
Volumes are mounted as the root user, so containers running as a non-root user (like n8n's node user) will hit permission errors. Set the environment variable RAILWAY_RUN_UID=0 on your n8n service and redeploy - this tells Railway to run the container as root, which will restore access to your volume data without affecting any existing files. More details in our volumes documentation.
Status changed to Awaiting User Response Railway • about 1 month ago
Status changed to Open Railway • about 1 month ago
Railway
Volumes are mounted as the root user, so containers running as a non-root user (like n8n's `node` user) will hit permission errors. Set the environment variable `RAILWAY_RUN_UID=0` on your n8n service and redeploy - this tells Railway to run the container as root, which will restore access to your volume data without affecting any existing files. More details in our [volumes documentation](https://docs.railway.com/volumes).
a month ago
Thanks, but RAILWAY_RUN_UID=0 is already set and the container now has full access to the volume — that part is solved.
The problem is different: after gaining access, the volume contains only an empty database.sqlite (~572 KB, fresh schema, 0 workflows). The original production data is not on the volume anymore. So this is not a permission issue — the data itself is gone after the plan-upgrade redeploy.
Could a human please check directly:
Is there ANY internal snapshot/backup of volume vol_3wker3c0h12rqut1 from before today's Hobby-plan upgrade?
If yes — restore it (or send me its prior contents).
If no snapshot exists — please confirm explicitly that the data is unrecoverable.
RUN_UID=0 restored access but the files are empty, so "without affecting existing files" doesn't apply here — the files are already gone. I need a real recovery check, not the permission fix. This is business-critical, paying customer.
a month ago
?