Login is disabled while the site is in read-only mode

(Thisgeekza) #1

This is a freshly bootstrapped docker system, database folder was removed so the database is new. I want to restore from backup, but now I’m locked out of the fresh instance - how do I disable this?

I suppose I should explain what I did.

As per Sam and my upgrade issue, I needed to (after backing the site up) destroy my containers and re-bootstrap them after renaming the /var/docker/shared/postgres_data folder. This I did, and I successfully gained access in to a fresh Discourse instance.

I enabled restore mode in settings, switched to backups tab, but the restore button was disabled on my backup files, citing ‘Restore mode is not enabled in settings’. I uploaded my backup file, which was successful, but was still unable to click the Restore button. Did a full refresh of the page (using Firefox), and the restore buttons enabled. I started the restore of my most recent backup.

It just sat on the log screen with the perpetual circle, with the last entry being [Creating Indexes] or something similar.
Using Chrome, I attempted to access the site, it was more or less back to normal, but missing a whole bunch of site settings and customized CSS, although there was a system message saying that the restore was complete.

I then went back to the backups tab (using Chrome), and wanted to try restoring again, but the restore buttons are again disabled, citing that ‘Restore is disabled in site settings’. I checked, and it IS enabled. So I tried unchecking it, and re-setting it, full re-freshing the page, but the Restore buttons would not enable under Chrome. I figured it might be because the site is active, so I clicked the ‘Enable Read Only Mode’. Nope, still no luck with the Restore buttons.

I then decided to start again from scratch. Destroyed the containers, deleted the postgres_data folder, and re-bootstrapped everything, only to be presented with ‘Login is disabled while the site is in read-only mode’ issue.

(Thisgeekza) #2

This might solve my issue…

It did. :stuck_out_tongue:

(Jacob) #3

This happened to me too. It’s easy enough to fix, but admins should be allowed to login while in read only mode.

(Sam Saffron) #4

I think the crux of the issue was that you were going for a clean site, but did not nuke the redis folder.

Also @zogstrip something is off with our restore there, it just appears that it never finishes.

(Thisgeekza) #5

When I got back in to the site, I used Chrome this time and performed the restore. I observed the same result (last log entry of CREATE INDEX with the “busy” spinner, however looking at /var/docker/shared/log/rails/unicorn.stdout.log showed me that the restore completed successfully.

It took a few browser cache clears before everything started behaving normally, but the restore worked like a charm, apart from the minor UI issue.

Also, I wasn’t aware that I had to nuke the redis folder, however I’ll know for next time. :wink:

(Régis Hanol) #6

I assume you mean when restoring from the web interface?

That’s because I use the MesssageBus to push the messages to the UI and once the database is restored, the session is lost and the user is no longer authenticated… Thus failing the long-polling

How to move from standalone setup to separate containers?
(Tobias Eigen) #7

FYI - I think this just happened to me today. Seemed to go on forever, no sign of it ever ending. When I refreshed the browser window I got the “Login is disabled while the site is in read-only mode”.

Would be nice to have a cleaner experience.

… now off to find out how to log in again. :slight_smile: