a month ago
Hi Railway team,
My Postgres service in project sanblafinance-strapi is failing to start with:
FATAL: private key file "/var/lib/postgresql/data/certs/server.key" must be owned by the database user or root
This started after a duplicate Postgres service (Postgres-UB-r) was created and then removed — it apparently left certs in the volume with wrong ownership.
The fix is a one-off chown postgres:postgres on that file inside the mounted volume. Data is intact; the cert just needs ownership reset.
Could you either:
Run the chown on the volume for me, or
Restore the most recent Postgres volume snapshot if available
I have important content in this database (CMS for sanbla.finance production site) and your AI agent suggested deleting the volume, which would be catastrophic. Please don't.
Project ID: f0d297f0-f79a-4e7b-a0ae-69adf73d184f
Service: Postgres (the one Strapi is using, ID f28720b6...)
Volume: postgres-volume (ID 8ef485ef...)
Thanks,
Pinned Solution
a month ago
For a one-time repair, set a temporary Start Command on the Postgres service that only fixes the certificate ownership/permissions:
bash -lc 'chown postgres:postgres /var/lib/postgresql/data/certs/server.key || sudo chown postgres:postgres /var/lib/postgresql/data/certs/server.key; chmod 600 /var/lib/postgresql/data/certs/server.key; ls -l /var/lib/postgresql/data/certs/server.key'
Deploy it once, confirm the command prints the file owned by postgres with 600 permissions, then remove the temporary Start Command and redeploy Postgres normally.
This lines up with the Railway Postgres SSL image: the template stores SSL files under /var/lib/postgresql/data/certs, and Postgres requires the private key to be owned by the database user or root with restrictive permissions.
If the file is missing or the volume still fails after the ownership fix, then the next safest step is restoring a volume snapshot, not deleting the volume.
3 Replies
Status changed to Open Railway • about 1 month ago
a month ago
You can set the start command of your postgres service to: bash -c "chown postgres:postgres /var/lib/postgresql/data/certs/server.key && chmod 600 /var/lib/postgresql/data/certs/server.key", and redeploy. once the container starts and runs the start command, you can remove it and redeploy again.
a month ago
For a one-time repair, set a temporary Start Command on the Postgres service that only fixes the certificate ownership/permissions:
bash -lc 'chown postgres:postgres /var/lib/postgresql/data/certs/server.key || sudo chown postgres:postgres /var/lib/postgresql/data/certs/server.key; chmod 600 /var/lib/postgresql/data/certs/server.key; ls -l /var/lib/postgresql/data/certs/server.key'
Deploy it once, confirm the command prints the file owned by postgres with 600 permissions, then remove the temporary Start Command and redeploy Postgres normally.
This lines up with the Railway Postgres SSL image: the template stores SSL files under /var/lib/postgresql/data/certs, and Postgres requires the private key to be owned by the database user or root with restrictive permissions.
If the file is missing or the volume still fails after the ownership fix, then the next safest step is restoring a volume snapshot, not deleting the volume.
ve-jo
For a one-time repair, set a temporary Start Command on the Postgres service that only fixes the certificate ownership/permissions: `bash -lc 'chown postgres:postgres /var/lib/postgresql/data/certs/server.key || sudo chown postgres:postgres /var/lib/postgresql/data/certs/server.key; chmod 600 /var/lib/postgresql/data/certs/server.key; ls -l /var/lib/postgresql/data/certs/server.key'` Deploy it once, confirm the command prints the file owned by postgres with 600 permissions, then remove the temporary Start Command and redeploy Postgres normally. This lines up with the Railway Postgres SSL image: the template stores SSL files under /var/lib/postgresql/data/certs, and Postgres requires the private key to be owned by the database user or root with restrictive permissions. If the file is missing or the volume still fails after the ownership fix, then the next safest step is restoring a volume snapshot, not deleting the volume.
a month ago
Worked perfectly, thank you so much. Set the temporary Start Command exactly as you suggested, the ls -l confirmed -rw------- 1 postgres postgres on server.key. Removed the override afterwards, Postgres came back up with the existing database intact (Skipping initialization → database system is ready to accept connections) and Strapi reconnected on the next restart. Marking your reply as the accepted solution.
Status changed to Solved mykal • about 1 month ago