Suddenly ECONNREFUSED

[summer wind]

I just yesterday discovered that my Overseerr was displaying the initial setup page when visiting its WebUI. Thanks to the Post Guidelines, I started digging into the logs and saw that it stopped finding the Plex server about six days ago, reporting an ECONNREFUSED: https://gist.github.com/SturmB/3c59f5c6f6dafb9d25fac14d7485327fj

I've checked that Plex is still very much available remotely, even through the internet, at the default port. I have made absolutely no changes to my setup for a long time, so I do not understand why Overseerr is suddenly getting ECONNREFUSED.

I am using TRaSH guides and have both Plex and Overseerr running in Docker containers (lscr.io/linuxserver/plex:latest and lscr.io/linuxserver/overseerr:latest, respectively) on the same Docker network. They are accessed through SWAG, a reverse-proxy. Again, no changes have been made to any of this setup for many months. The only thing that has changed recently is sharing my Plex libraries with three new users.

What can I do to get it to see Plex again? Do I need to go through that first-time setup again as shown in the attached screenshot? Will that destroy the history of users and requests and such?

[river river]

how do you have overseerr configured, volumes? if you look at where it's suposed to be set, do you see files?

[summer wind]

Thank you for responding, @river river.

My Overseerr container is configured thusly: https://gist.github.com/SturmB/21b5ff3fce3d59173691328bfbc36140

The files definitely exist, including the db/ and logs/ folders and their contents. Oddly, in the settings.json file, the Plex information is mostly empty; no name, IP, libraries, etc. The same is true for Radarr, Sonarr, etc.

I do not know how or why that information got wiped out, unless a recent update to the Overseerr Docker image did it.

[river river]

If you remove the /setup at the end of the URL does it bring you back to that page?

[summer wind]

Yes, it redirects back to it. Which makes sense because of those missing values in the settings.json file.

I don't mind going through the setup procedure again as long as it's safe to do so. i.e., all the previous request data is preserved. (And, I suppose, it's not really all that important, so if that data gets wiped, I think I can live with that, too.)