The volume on that service is currently 500 MB and nearly full (~500 MB used), which explains both the "disk is full" and "database is locked" SQLite errors. The resize attempt was set to 5120 MB, which exceeds the Hobby plan's maximum volume size of 5000 MB, so it did not go through. Setting the volume size to 5000 MB or below and applying the change should give your database the room it needs.

Hello Railway Support,

I need assistance with a persistent volume issue affecting my production application.

Project: laudable-fascination

Service: MEEKARO-TECH-FMOS-CLOUD

Service ID: 71221f80-9720-44c9-a634-8e8ac303f0ef

Volume ID: b75a2e40-de5b-4568-830d-6c50074bea8c

Mount path: /data

The volume was originally 500 MB and became full. My application began producing:

sqlite3.OperationalError: database or disk is full

I subsequently used Railway's Live Resize function to increase the existing volume to 5 GB, without deleting, detaching, or recreating the volume.

The service has also been restarted/remounted after the resize.

However, after the resize and restart, the application again produced:

sqlite3.OperationalError: database or disk is full

We have also observed:

sqlite3.OperationalError: database is locked

The main database /data/fmos.db is approximately 444 MB, so it should now be well below a properly mounted 5 GB filesystem.

There has also been conflicting Railway state: the dashboard/configuration indicates the volume was increased to 5 GB, while some Railway service/backend status information has continued to report 500 MB.

Please verify from Railway's infrastructure side:

The actual filesystem capacity currently presented to /data inside the running container.

Whether the 5 GB resize was fully propagated to the underlying filesystem.

Whether there is any remaining 500 MB filesystem/quota limitation despite the volume being configured for 5 GB.

Whether another Railway storage or filesystem condition could cause SQLite to receive database or disk is full.

Important: Please do not delete, detach, recreate, or replace the existing volume, because it contains my production database. I need the existing volume investigated and corrected in place.

Thank you.

Hello Railway Support,

I need assistance with a persistent volume issue affecting my production application.

Project: laudable-fascination

Service: MEEKARO-TECH-FMOS-CLOUD

Service ID: 71221f80-9720-44c9-a634-8e8ac303f0ef

Volume ID: b75a2e40-de5b-4568-830d-6c50074bea8c

Mount path: /data

The volume was originally 500 MB and became full. My application began producing:

sqlite3.OperationalError: database or disk is full

I subsequently used Railway's Live Resize function to increase the existing volume to 5 GB, without deleting, detaching, or recreating the volume.

The service has also been restarted/remounted after the resize.

However, after the resize and restart, the application again produced:

sqlite3.OperationalError: database or disk is full

We have also observed:

sqlite3.OperationalError: database is locked

The main database /data/fmos.db is approximately 444 MB, so it should now be well below a properly mounted 5 GB filesystem.

There has also been conflicting Railway state: the dashboard/configuration indicates the volume was increased to 5 GB, while some Railway service/backend status information has continued to report 500 MB.

Please verify from Railway's infrastructure side:

The actual filesystem capacity currently presented to /data inside the running container.

Whether the 5 GB resize was fully propagated to the underlying filesystem.

Whether there is any remaining 500 MB filesystem/quota limitation despite the volume being configured for 5 GB.

Whether another Railway storage or filesystem condition could cause SQLite to receive database or disk is full.

Important: Please do not delete, detach, recreate, or replace the existing volume, because it contains my production database. I need the existing volume investigated and corrected in place.

Thank you.

The volume is still 500 MB and completely full (~500 MB used), which is why the SQLite errors continue. The resize to 5 GB was entered as 5120 MB (5 × 1024), which is 120 MB over the Hobby plan's 5000 MB cap, so it was refused and never applied to the underlying storage. The "5 GB" you see in the dashboard is that failed change sitting unapplied, which is also the source of the conflicting state. You can dismiss the failed change, then set the volume to 5000 MB and deploy - that will resize the volume and give your database the space it needs without any data loss.

Hello Railway Support,

I need assistance with a persistent volume issue affecting my production application.

Project: laudable-fascination

Service: MEEKARO-TECH-FMOS-CLOUD

Service ID: 71221f80-9720-44c9-a634-8e8ac303f0ef

Volume ID: b75a2e40-de5b-4568-830d-6c50074bea8c

Mount path: /data

The volume was originally 500 MB and became full. My application began producing:

sqlite3.OperationalError: database or disk is full

I subsequently used Railway's Live Resize function to increase the existing volume to 5 GB, without deleting, detaching, or recreating the volume.

The service has also been restarted/remounted after the resize.

However, after the resize and restart, the application again produced:

sqlite3.OperationalError: database or disk is full

We have also observed:

sqlite3.OperationalError: database is locked

The main database /data/fmos.db is approximately 444 MB, so it should now be well below a properly mounted 5 GB filesystem.

There has also been conflicting Railway state: the dashboard/configuration indicates the volume was increased to 5 GB, while some Railway service/backend status information has continued to report 500 MB.

Please verify from Railway's infrastructure side:

The actual filesystem capacity currently presented to /data inside the running container.

Whether the 5 GB resize was fully propagated to the underlying filesystem.

Whether there is any remaining 500 MB filesystem/quota limitation despite the volume being configured for 5 GB.

Whether another Railway storage or filesystem condition could cause SQLite to receive database or disk is full.

Important: Please do not delete, detach, recreate, or replace the existing volume, because it contains my production database. I need the existing volume investigated and corrected in place.

Thank you.

The answer has not changed from our earlier replies on this thread. The volume is still 500 MB and completely full because the resize was refused, not because it failed to propagate. Entering "5 GB" submitted 5120 MB (5 × 1024), which is 120 MB over the Hobby plan's 5000 MB volume cap, so it was rejected and the volume was never touched. The "5 GB" the dashboard shows is that rejected staged change, not the live volume size. To resolve this: dismiss the failed change in the deploy bar, set the volume size to 5000 MB, and deploy. Your data is safe and no volume replacement is needed.

The place where I am to make this changes have been locked and not actionable

The environment is not locked. The refused resize is showing an error on the deploy bar, but you can dismiss it using the three-dot menu on that bar and choose "Discard Changes." Once dismissed, open the volume settings, enter 5000 as the size in MB, and deploy. The previous attempt used 5120 MB (5 × 1024), which exceeds the Hobby plan's 5000 MB maximum, so it was refused. Entering 5000 MB directly will go through, and your data stays untouched.

I have checked the Railway project on both desktop and mobile. There is no deploy bar showing the failed resize, and there is no “Discard Changes” option visible anywhere.

The live volume is still 500 MB.

Please either resize the existing volume directly to 5000 MB from your side, or provide the exact current UI path where this failed resize can be dismissed.

Volume ID: b75a2e40-de5b-4568-830d-6c50074bea8c

The volume is confirmed at 500 MB and completely full. The resize submitted 5120 MB (5 x 1024), which exceeds the Hobby plan's 5000 MB cap (5 x 1000), so it was refused and the volume was never changed. That is why the dashboard showed a different size than the actual volume. The correct value is 5000 MB. Your data is safe and untouched.