16 days ago
Subject: Postgres Volume Mount Configuration Not Syncing - Deployment Crashes
Issue: Postgres service is crashing due to conflicting volume mount configurations. The error message indicates two volumes are being mounted to the same path, but the dashboard and API configurations are out of sync.
Error Message:
Railway volume not mounted to the correct path,
expected /var/lib/postgresql/data but got /var/lib/postgresql/data,/var/lib/postgresql/data
Background: We had a Postgres database with an existing volume (postgres-volume-vQ9I, 5 GB) containing production data. We created a new 10 GB volume to recover the database after a potential data loss incident.
Current Configuration:
- Old Volume: postgres-volume-vQ9I (5 GB) - should be mounted to
/var/lib/postgresql/data - New Volume: 8d455635-f955-481c-acb7-761cfaa1c76b (10 GB) - should be removed or mounted elsewhere
Problem:
- Dashboard shows: postgres-volume-vQ9I mounted to
/var/lib/postgresql/data - API configuration shows: New volume (8d455635-f955-481c-acb7-761cfaa1c76b) mounted to
/var/lib/postgresql/data - Multiple deployment attempts fail with the same error
- Changes made in the dashboard are not reflected in the API
Attempted Solutions:
- Modified volume mount paths via dashboard
- Attempted to update via API (updateServiceTool)
- Removed the new volume via API
- Multiple redeployments - all failed
Current Status:
- Postgres service: CRASHED
- Latest deployment ID: 6877e9d7-6466-4aa3-b778-7fc0571cfaf0
- Old volume (postgres-volume-vQ9I) with production data: Still intact but inaccessible
Request: Please help resolve the volume mount configuration sync issue so we can restore the Postgres service with the old volume containing our production data.
1 Replies
Status changed to Awaiting Railway Response Railway • 16 days ago
15 days ago
This thread has been marked as public for community involvement, as it does not contain any sensitive or personal information. Any further activity in this thread will be visible to everyone.
Status changed to Open Railway • 15 days ago
10 days ago
This looks like a duplicate volume mount state, not a Postgres data corruption problem.
The important clue is this part:
expected /var/lib/postgresql/data but got /var/lib/postgresql/data,/var/lib/postgresql/data
That usually means the deployment resolver is seeing two volume instances for the same service/environment/path and joins both mount paths. Postgres then never starts because Railway refuses the ambiguous mount. I would avoid any action that writes to the old volume until the duplicate mount is cleared.
Suggested recovery path:
- Stop redeploy loops for the Postgres service. Keep the old 5 GB volume intact.
- Use the Railway CLI/API as source of truth, not the dashboard view, and list the actual volume instances attached to the affected service/environment.
- Detach only the new 10 GB volume instance from the Postgres service. Do not delete the old production volume.
- Ensure exactly one remaining volume instance is attached to the Postgres service at
/var/lib/postgresql/data: the oldpostgres-volume-vQ9Ivolume. - Redeploy only after the API/CLI shows one mount for that service/path.
CLI shape, after linking the project/environment:
railway volume list --json
railway volume detach --volume 8d455635-f955-481c-acb7-761cfaa1c76b --service <postgres-service>
railway volume update --volume postgres-volume-vQ9I --service <postgres-service> --mount-path /var/lib/postgresql/data
railway redeploy --service <postgres-service>
If railway volume list --json already shows only one volume but deployments still fail with the comma-separated path, then this is likely stale backend state on Railway's side. In that case the precise support ask is: please remove the stale volume instance/mount for 8d455635-f955-481c-acb7-761cfaa1c76b from the affected Postgres service/environment, because the deploy resolver is still returning two mounts for /var/lib/postgresql/data even though the dashboard shows one.
After it boots, first run a read-only sanity check before letting app traffic back in:
psql "$DATABASE_URL" -c 'select current_database(), now();'
psql "$DATABASE_URL" -c '\dt'
Do not attach the old volume to a brand-new Postgres container with a different major version unless you know the original Postgres major version. A major-version mismatch can make recovery noisier even if the volume data is intact.