Screwed up my Ombi install

I have Ombi v3. Yesterday I saw that an update was available, and without thinking, tried to update it from the Ombi built-in updater. Then I realized that you’re supposed to use “sudo upgradeOmbi” so I did that. Then I opened the Ombi website and nothing was loading, so I decided to just uninstall it and reinstall it. However, that didn’t work. When I reinstalled it, everything was gone but it didn’t give me the setup wizard, and I was already logged in, but didn’t know my password. I changed the base path to /ombi and now when I visit ‘’, the dark gray omni background is there, and the orange loading stripe at the top, but nothing else. It’s also asking for digest auth, even though ombi.conf has “Require all granted”. How did I break this?


The proxy settings need to be changed

dont forget to add Require all granted at the end of the location section

I changed the proxy settings to what was shown in the guide, changing to my actual website. Restarted Apache and Ombi but I’m still having the same problem. It’s on a subdomain, is that in any way related?


Did you add that?

Yes I did.

<Location /ombi>
Allow from
ProxyPass "" connectiontimeout=5 timeout=30 keepalive=on
ProxyPassReverse ""
Require all granted
RewriteEngine on
RewriteRule ^/ombi$ [R=301,L]
RewriteCond %{HTTP_REFERER} ""
RewriteCond %{REQUEST_URI} !^/ombi
RewriteRule ^(.*)$ /ombi [R=301,L]

If you’re running it on a subdomain, ie; then this could be an issue as the reverse is setting it up for Looking at your reverse, I don’t think that’s the case. Running from shouldn’t pose any issues though.

Additionally, the reverse should already have the require all granted field added as per this in the Ombi install package:

function _services() {
  cp ${local_setup}templates/sysd/ombi.template /etc/systemd/system/ombi.service
  sed -i "s/USER/${user}/g" /etc/systemd/system/ombi.service
  systemctl enable ombi >/dev/null 2>&1
  systemctl start ombi
  touch /install/.ombi.lock
  cat > /etc/apache2/sites-enabled/ombi.conf <<EOF
<Location /ombi>
ProxyPass http://localhost:5000/ombi
ProxyPassReverse http://localhost:5000/ombi
Require all granted

Not really sure what the other fields there are for, I understand the need for https, although, this should require forcing the rewrite as in my testing https will work without it.

The whole server is on a subdomain, like It’s definitely something wrong with the Apache config, because it is still showing the gray background and orange stripe.

Can you set your ombi.conf to the default and restart apache and try to access it once more, clearing cache etc before attempting to access the Wizard?

<Location /ombi>
ProxyPass http://localhost:5000/ombi
ProxyPassReverse http://localhost:5000/ombi
Require all granted

I am going to test this on a VM with a subdomain real quick to see if I can duplicate this issue.

It’s strange you have this issue as we serve DNS on to some members and this issue doesn’t present itself.


Just tested this on a subdomain and it went through without issue.

Just tested without port and the rev proxy at and you’re right, not loading properly. I am going to set some logs and see what this is all about.

Do you still need me to reset ombi.conf to the default and try to access it again?

No, I had that initially and it appears that Ombi is not processing the reverse properly (obviously I know). This wasn’t so much an issue even a week ago, so I need to figure why this isn’t working, be it an update in Ombi or something on the end of QuickBox… which I doubt.

I’ll continue looking into it and try to get this sorted with haste. Thanks for pointing it out!

1 Like

I think something changed on Ombi’s end, because the wiki page was only started 12 days ago. Previously I had my version of Ombi up and running, and then when I updated, the new version stopped working through the rev proxy. It still works perfectly fine at localhost:5000 though. The wiki page says:

The url rewrite is required after version 3.0.2517. This rewrites all requests to /dist/* to /ombi/dist/*

1 Like

Yeah, trying to sort out the file structure and requirements now for a proper reverse. As soon as one reverse works with the modifications, tidus goes and changes something again without notice that breaks functionality. Been digging through the logs and they appear to be irrelevant to anything we actually need.


Ok, so I checked the option in settings Ignore Any Certificate Errors >> sent a reload to Ombi. I can now at least see Ombi, however, it’s forcing a login page… one in which I never permitted to show.



So I kept getting a login screen that was requesting username/password, it kept informing me the password was wrong.

Typed in to access the Wizard one more time. Skipped most options other than entering in the Username and Password fields. Now it appears I can access Ombi on the subdomain and the user is there.

Note: This is with the default ombi.conf. Additionally, you can uncheck the “Ignore Any Certificate Errors” field, it works regardless, we’re just having to run the Wizard twice :confused: .


Give that a go and see if it works out for you. Still not sure why we would have to manually run through the Wizard twice to get the settings to stick. Hopefully this is addressed sooner than later… and hopefully, this method works for you as well.

1 Like

I don’t think it’s working… I don’t have problems with logging in, but I also don’t have access to the wizard. redirects to, I can log out and log in but the only thing I’m getting is the gray background, the navbar at the top, and the orange stripe. This was without the rewrite rules.


Hmm, this is both strange and frustrating. Will you run upgradeOmbi one more time and try again? Additional to this, it should have the logo as Ombi and not Plex Requests. Are you on a current version of QuickBox?

I changed Ombi’s Application Name, you can change the Ombi in the top left corner to anything you want.
Ran sudo upgradeOmbi, here’s the log from the last two runs:

[info] Verboity level: [none]
[debug] Update script running as: root
[info] Ombi service file for systemd found…parsing…
[info] Parsing complete: InstallDir: /opt/Ombi/, User: ----, Group: ----
[info] Downloading Ombi update…
[info] Checking for latest version
[debug] latestversion: 3.0.2776
[debug] jobId: jqegwte5rpdg49ed
[debug] version: 3.0.2776
[info] Latest version: 3.0.2776…determining expected file size…
[debug] size: 47271237
[info] Expected file size: 47271237…downloading…
[info] Version 3.0.2776 downloaded…checking file size…
[info] File size validated…checking Ombi service status…
[info] Ombi is not active…installing update…
[info] Update installed…setting ownership…
[info] Ownership set…not starting Ombi
[info] Cleaning up…
[info] Update complete
[info] Verboity level: [none]
[debug] Update script running as: root
[info] Ombi service file for systemd found…parsing…
[info] Parsing complete: InstallDir: /opt/Ombi/, User: ----, Group: ----
[info] Downloading Ombi update…
[info] Checking for latest version
[debug] latestversion:
[debug] jobId:
[debug] version:
[crit] Build version does not match expected version

Pretty sure this means it’s up to date. localhost:5000 also says it’s up to date. Version 3.0.2776

Can I PM you so I can check this on your server? 3.0.2328 is the latest version

Sure. ____

Just wanted to add that I’m also having the same issue as kilometers. Never had an issue until recently. I’m now seeing the Ombi page with only the gray background. My server is on a QB subdomain and my cert has expired.

@JMSolo Please let me know if you need another server to test. Thank!

Yeah, this appears to be an issue with Ombi using subdomains on a reverse as regular have no problem. @j0hnwick, what version of Ombi are you using? Also, I am sure it already is populated, so in the meantime, it may result in needing to access via until I figure out a proper reverse for Ombi.

@JMSolo I believe I’m running the most current version 3.0.2820.