Describe the bug
After first installing and starting Ombi, the page is stuck on "Loading..." with nothing happening
To Reproduce
Steps to reproduce the behavior:
Expected behavior
The OOBE should begin shortly after opening the page
Logs (Logs directory where Ombi is located)
Server log:
2020-04-11 01:42:49.866 +00:00 [Information] Default Quartz.NET properties loaded from embedded resource file
2020-04-11 01:42:49.945 +00:00 [Debug] TaskSchedulingThreadPool configured with max concurrency of 10 and TaskScheduler ThreadPoolTaskScheduler.
2020-04-11 01:42:49.953 +00:00 [Information] Initialized Scheduler Signaller of type: Quartz.Core.SchedulerSignalerImpl
2020-04-11 01:42:49.955 +00:00 [Information] Quartz Scheduler v."3.0.7.0" created.
2020-04-11 01:42:49.958 +00:00 [Information] RAMJobStore initialized.
2020-04-11 01:42:49.963 +00:00 [Information] Scheduler meta-data: Quartz Scheduler (v3.0.7.0) 'DefaultQuartzScheduler' with instanceId 'NON_CLUSTERED'
Scheduler class: 'Quartz.Core.QuartzScheduler' - running locally.
NOT STARTED.
Currently in standby mode.
Number of jobs executed: 0
Using thread pool 'Quartz.Simpl.DefaultThreadPool' - with 10 threads.
Using job-store 'Quartz.Simpl.RAMJobStore' - which does not support persistence. and is not clustered.
2020-04-11 01:42:49.963 +00:00 [Information] Quartz scheduler 'DefaultQuartzScheduler' initialized
2020-04-11 01:42:49.963 +00:00 [Information] Quartz scheduler version: 3.0.7.0
2020-04-11 01:42:49.964 +00:00 [Information] JobFactory set to: Ombi.Schedule.IoCJobFactory
2020-04-11 01:42:50.092 +00:00 [Information] Scheduler DefaultQuartzScheduler_$_NON_CLUSTERED started.
2020-04-11 01:42:50.101 +00:00 [Debug] Batch acquisition of 0 triggers
2020-04-11 01:43:23.037 +00:00 [Information] Default Quartz.NET properties loaded from embedded resource file
2020-04-11 01:43:23.140 +00:00 [Debug] TaskSchedulingThreadPool configured with max concurrency of 10 and TaskScheduler ThreadPoolTaskScheduler.
2020-04-11 01:43:23.150 +00:00 [Information] Initialized Scheduler Signaller of type: Quartz.Core.SchedulerSignalerImpl
2020-04-11 01:43:23.152 +00:00 [Information] Quartz Scheduler v."3.0.7.0" created.
2020-04-11 01:43:23.154 +00:00 [Information] RAMJobStore initialized.
2020-04-11 01:43:23.159 +00:00 [Information] Scheduler meta-data: Quartz Scheduler (v3.0.7.0) 'DefaultQuartzScheduler' with instanceId 'NON_CLUSTERED'
Scheduler class: 'Quartz.Core.QuartzScheduler' - running locally.
NOT STARTED.
Currently in standby mode.
Number of jobs executed: 0
Using thread pool 'Quartz.Simpl.DefaultThreadPool' - with 10 threads.
Using job-store 'Quartz.Simpl.RAMJobStore' - which does not support persistence. and is not clustered.
2020-04-11 01:43:23.160 +00:00 [Information] Quartz scheduler 'DefaultQuartzScheduler' initialized
2020-04-11 01:43:23.160 +00:00 [Information] Quartz scheduler version: 3.0.7.0
2020-04-11 01:43:23.161 +00:00 [Information] JobFactory set to: Ombi.Schedule.IoCJobFactory
2020-04-11 01:43:23.290 +00:00 [Information] Scheduler DefaultQuartzScheduler_$_NON_CLUSTERED started.
2020-04-11 01:43:23.298 +00:00 [Debug] Batch acquisition of 0 triggers
Client log:
Chrome:
Uncaught SyntaxError: Unexpected token '<' app.js:1
Firefox:
SyntaxError: expected expression, got '<' app.js:1
Desktop (please complete the following information):
Ombi Version (please complete the following information):
I've tried both the latest release v3.0.4892
and the latest dev build v3.0.5115-develop
Hi!
Thanks for the issue report. Before a real human comes by, please make sure you used our bug report format.
Have you looked at the wiki yet? https://github.com/tidusjar/ombi/wiki/
Before posting make sure you also read our FAQ.
Make the title describe your issue. Having 'not working' or 'I get this bug' for 100 issues, isn't really helpful.
If we need more information or there is some progress we tag the issue or update the tag and keep you updated.
Thanks!
Ombi Bot.
@SleeplessSloth -- I had the same problem. For some reason a hard reload of the page was the only thing that would get past the loading screen (I also had identical console errors and logs). In Chrome, open developer tools, then right click the normal refresh button and choose hard reset.
Didn't work, there's no difference between a normal reload and a hard reset sadly
Very odd indeed. The error actually came back for me after a restart of Ombi. My only recourse was to stop the service, wipe out any trace of the config file, and run it again. (I run it as a docker container).
Restarting or changing versions did nothing to help the problem. Only once I completed deleted the config folder.
how are you starting ombi up? Are you passing any args?
for me, docker compose:
ombi:
# image: linuxserver/ombi ## Previously used image, I don't believe it ever happened on here but I only used it for a few hours before swapping to v4 preview
image: linuxserver/ombi:v4-preview
container_name: ombi
environment:
- PUID=${PUID} # default user id, defined in .env
- PGID=${PGID} # default group id, defined in .env
- TZ=${TZ} # timezone, defined in .env
- BASE_URL=/ombi #optional
volumes:
- /mnt/external/downloader/config/ombi:/config
- /mnt/external/downloader/config/ombi/Logs:/opt/ombi/Logs
ports:
- 3579:3579
restart: unless-stopped
./Ombi --host 'http://*:62156' --baseurl '/foo/ombi'
in my case. I have somehow worked around the bug by not connecting from the internet but by using ssh -L
for the first setup. After that everything has seemed to work okay. That couldn't be something like ports being not open or whatnot since I could connect to the page just fine but all I saw was "Loading..."
I'm getting the same results. Even with the newest version release I can still only get the page to load via localhost, and even then it never makes it past the loading screen. Also seeing the same error in chrome developer tools of an unexpected <.
It works when accessed from the internet via reverse proxy, but does not work when accessed directly
I am also experiencing this issue on v4.0.365.
From my testing it looks to be linked to setting the base url. When the base url is set and the container restarted, it is not possible to access Ombi. And when appending the base url, a blank white screen appears as though it was not set at all.
If you have applied a base URL then you need to access ombi through a reverse proxy
@tidusjar in v4.0.365 when attempting to access via reverse proxy with the base url set, the page appears blank/white, and the console shows the error SyntaxError: expected expression, got '<'
.
When attempting to access via ip:port/base-url, it redirects to not using the base url at all, and intermittently becomes stuck on the colourful loading screen.
And you restarted ombi after making the Base URL change right?
What are you using to reverse proxy it?
Correct, restarted Ombi, and changed my reverse proxy from pointing to my Ombi v3 instance to my v4 instance, no other settings changed. The v3 instance works perfectly with no issues accessing with the base URL.
Reverse proxy is Nginx
@tidusjar
Screenshot showing the database setting showing the base url and showing attempting to access it using Nginx reverse proxy.
Please share your proxy config
See attached text file. Ombi is being redirected too as per the /request location.
As noted above, with v3, the reverse proxy is working correctly, it's just v4 that is having issues.
I just attempted to upgrade from v3 to v4 and I am having the same behavior. Accessing it through the nginx reverse proxy just produces a white screen. Accessing it directly via port 3579, with or without the /plexreq/ in the URL produces a colored loading screen that spins endlessly. Firefox console shows SyntaxError: expected expression, got '<'
Using the latest linuxserver.io Ombi and Let'sEncrypt containers.
ombi:
image: linuxserver/ombi:v4-preview
container_name: ombi
volumes:
- /chobi/dockerdata/ombi:/config
environment:
- PGID=774200006
- PUID=774200016
- TZ=America/New_York
- BASE_URL=/plexreq
ports:
- '3579:3579'
restart: unless-stopped
location /plexreq {
return 301 $scheme://$host/plexreq/;
}
location ^~ /plexreq/ {
# enable the next two lines for http auth
#auth_basic "Restricted";
#auth_basic_user_file /config/nginx/.htpasswd;
# enable the next two lines for ldap auth, also customize and enable ldap.conf in the default conf
#auth_request /auth;
#error_page 401 =200 /login;
include /config/nginx/proxy.conf;
resolver 127.0.0.11 valid=30s;
set $upstream_app ombi;
set $upstream_port 3579;
set $upstream_proto http;
proxy_pass $upstream_proto://$upstream_app:$upstream_port;
}
# This allows access to the actual api
location ^~ /plexreq/api {
include /config/nginx/proxy.conf;
resolver 127.0.0.11 valid=30s;
set $upstream_app ombi;
set $upstream_port 3579;
set $upstream_proto http;
proxy_pass $upstream_proto://$upstream_app:$upstream_port;
}
if ($http_referer ~* /plexreq) {
rewrite ^/api/(.*) /plexreq/api/$1? redirect;
}
# This allows access to the documentation for the api
location ^~ /plexreq/swagger {
include /config/nginx/proxy.conf;
resolver 127.0.0.11 valid=30s;
set $upstream_app ombi;
set $upstream_port 3579;
set $upstream_proto http;
proxy_pass $upstream_proto://$upstream_app:$upstream_port;
}
if ($http_referer ~* /plexreq) {
rewrite ^/swagger/(.*) /plexreq/swagger/$1? redirect;
}
I'm seeing the same errors and issues on my install as well.
Switch my docker container to use the v4-preview tag of the linuxserver.io container. The container starts and doesn't show any errors in it's stdout logs. However, when attempting to access the interface I just get a spinning loading screen.
Getting the same issues with my install (blank white screen) using the v4-preview docker tag.
My nginx reverse proxy config for reference:
location /ombi {
proxy_pass http://127.0.0.1:5000/ombi;
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection $http_connection;
proxy_set_header Host $proxy_host;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_redirect off;
}
I tried removing all my databases and doing a completely fresh setup of the v4-preview container and it still didn't work. Ombi doesn't seem to honor the baseurl setting at all in v4. I was able to get to the instance without using a baseurl, but absolutely could not get the baseurl to work with or without an nginx reverse proxy in front of it.
I'm seeing the same loading issue with v4 running on a Qnap. Had to revert back to using v3.
I am having the same problem. With a base url, you are stuck on loading../blank screen for direct connect/nginx reverse proxy respectively.
If I remove the base url, it works as expected.
OK,
When using a reverse proxy, if you are passing in the baseurl as a startup argument all good, if you are setting it in the Settings pages, Ombi requires a restart.
Then you need to make sure your Proxy Config is all good see here: https://github.com/tidusjar/Ombi/wiki/Reverse-Proxy-v4
Once you have changed your proxy config ensure you restart Nginx. You should be then able to access V4 via the proxy address.
It looks like the reverse proxy config is correct. Also the *rr apps works through the proxy.
The ombi android app also still works through the reverse proxy, also if you view page source in the webbrowser, you can see that there is code there.
I can see that basepath is '/' in the javascript below, even though basepath is /ombi in the database. Could that have something to do with it?
 | <!DOCTYPE html>
-- | --
 | <html lang="en">
 | Â
 | <head>
 | <script type='text/javascript'>
 | function configExists(url) {
 | var req = new XMLHttpRequest();
 | req.open('GET', url, false);
 | req.send();
 | return req.status === 200 && req.responseURL === url;
 | }
 | Â
 | var probePath = 'styles/please-wait.js';
 | var origin = document.location.origin;
 | var pathSegments = document.location.pathname.split('/');
 | Â
 | var basePath = '/'
 | var configFound = false;
 | for (var i = 0; i < pathSegments.length; i++) {
 | var segment = pathSegments[i];
 | if (segment.length > 0) {
 | basePath = basePath + segment + '/';
 | }
 | var fullPath = origin + basePath + probePath;
 | configFound = configExists(fullPath);
 | if (configFound) {
 | break;
 | }
 | }
 | var basePathToUse = basePath.substring(0, basePath.length - 1); // trim off the trailing '/'
 | basePathToUse == '' ? '/' : basePathToUse;
 | window["baseHref"] = configFound ? basePathToUse : '/';
 | Â
 | document.write("<base href='" + (configFound ? basePath : '/') + "' />");
 | Â
 | console.log(window["baseHref"]);
 | </script>
 | <link href="https://fonts.googleapis.com/icon?family=Material+Icons" rel="stylesheet">
 | <link href="https://fonts.googleapis.com/css?family=Roboto:300,400,500" rel="stylesheet">
 | <link href="styles/please-wait.css" rel="stylesheet">
 | <link href="styles/spinkit.css" rel="stylesheet">
 | <link href="styles/11-folding-cube.css" rel="stylesheet">
 | <link rel="icon" type="image/png" href="images/favicon/favicon.ico"/>
 | <script src="styles/please-wait.js"></script>
 | <meta charset="utf-8" />
 | <meta name="viewport" content="width=device-width, initial-scale=1.0" />
 | <meta property="og:image:height" content="375" />
 | <meta property="og:image:width" content="991" />
 | <meta property="og:image" content="~/images/logo.png" />
 | <meta property="og:site_name" content="Ombi" />
 | <meta property="og:title" content="Ombi" />
 | <meta property="og:type" content="website" />
 | <meta property="og:description" content="Ombi, media request tool">
 | Â
 | <title>Ombi</title>
 | Â
 | <link href="https://fonts.googleapis.com/css?family=Roboto:300,400,500&display=swap" rel="stylesheet">
 | <link rel="stylesheet" href="styles.f86c5adfa764c951f59e.css"><link rel="stylesheet" href="main.505174cd50b2102321f0.css"></head>
 | Â
 | <body class="mat-typography custom-background">
 | Â
 | <app-ombi>
 | <script type="text/javascript">
 | var colors = ["#f44336", "#f44336", "#9c27b0", "#673ab7", "#3f51b5", "#2196f3", "#03a9f4", "#00bcd4", "#009688", "#4caf50", "#cddc39", "#ffeb3b", "#ffc107", "#ff9800", "#ff5722", "#9e9e9e", "#607d8b"];
 | var bgColor = colors[Math.floor(Math.random() * colors.length)];
 | window.loading_screen = window.pleaseWait({
 | // logo: "assets/images/logo.png",
 | template: `<div class='pg-loading-inner'>
 | <div class='pg-loading-center-outer'>
 | <div class='pg-loading-center-middle'>
 | <h1 class='pg-loading-logo-header'>
 | </h1>
 | <div class='pg-loading-html'>
 | </div>
 | Loading
 | </div>
 | </div>
 | </div>`,
 | backgroundColor: bgColor,
 | loadingHtml: "<div class='sk-folding-cube'><div class='sk-cube1 sk-cube'></div><div class='sk-cube2 sk-cube'></div><div class='sk-cube4 sk-cube'></div><div class='sk-cube3 sk-cube'></div></div>"
 | });
 | </script>
 | </app-ombi>
 | <script src="runtime.74394d19e9b47be0a522.js" defer></script><script src="polyfills-es5.6308fbeb21f20fe59dcd.js" nomodule defer></script><script src="polyfills.330e93a5e634aa70f222.js" defer></script><script src="scripts.1b13958999223135db0e.js" defer></script><script src="main.94f96b7704ff9c0d7172.js" defer></script></body>
 | Â
 | </html>
 | Â
and what is the URL you are accessing ombi on?
Can you also provide the console logs from the browser?
https://aaa.duckdns.org/ombi or http://192.168.0.40:3579. I get the same errors in console for both urls:
(index):8 [Deprecation] Synchronous XMLHttpRequest on the main thread is deprecated because of its detrimental effects to the end user's experience. For more help, check https://xhr.spec.whatwg.org/.
configExists @ (index):8
(index):36
runtime.74394d19e9b47be0a522.js:1 Uncaught SyntaxError: Unexpected token '<'
polyfills.330e93a5e634aa70f222.js:1 Uncaught SyntaxError: Unexpected token '<'
scripts.1b13958999223135db0e.js:1 Uncaught SyntaxError: Unexpected token '<'
main.94f96b7704ff9c0d7172.js:1 Uncaught SyntaxError: Unexpected token '<'
2(index):1 Unchecked runtime.lastError: The message port closed before a response was received.
DevTools failed to load SourceMap: Could not load content for chrome-extension://oaaadlnghojigbibgkbalkkmbfkakkbe/polyfills/promise-7.0.4.min.js.map: HTTP error: status code 404, net::ERR_UNKNOWN_URL_SCHEME
DevTools failed to load SourceMap: Could not load content for chrome-extension://oaaadlnghojigbibgkbalkkmbfkakkbe/libs/underscore-min.map: HTTP error: status code 404, net::ERR_UNKNOWN_URL_SCHEME
DevTools failed to load SourceMap: Could not load content for chrome-extension://oaaadlnghojigbibgkbalkkmbfkakkbe/libs/backbone-min.map: HTTP error: status code 404, net::ERR_UNKNOWN_URL_SCHEME
DevTools failed to load SourceMap: Could not load content for chrome-extension://gabdloknkpdefdpkkibplcfnkngbidim/maps/content.min.js.map: HTTP error: status code 404, net::ERR_UNKNOWN_URL_SCHEME
"Unexpected token '<'" are usually the result of an invalid reference to a resource as the filename is hashed and the site returns a 404 page which begins with a <
When accessing https://aaa.duckdns.org/ombi
what is the Base Href in the DOM?
The base path is /
On Tue, Oct 13, 2020 at 9:44 AM Jamie notifications@github.com wrote:
When accessing https://aaa.duckdns.org/ombi what is the Base Href in the
DOM?—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/tidusjar/Ombi/issues/3483#issuecomment-707556914, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AACLJXJCQG2VC3GLXGTLYIDSKQAONANCNFSM4MF2A5EQ
.
--
/Jörgen Bergström
The problem with the baseurl is with the entrypoint html's javascript and how linuxserver has built their swag/letsencrypt container.
By default the linuxserver's letsencrypt nginx is configured to return the nginx/www/index.html for the default "/" location -- see site-confs/default, root is set to config/www, which corresponds to your conf/nginx/www folder and location / block is set to try_files /index.html among others.
In src/Ombi/ClientApp/src/index.html line 15 you split the pathname by a forwardslash, which for a subfolder (ending with a forwardslash also as per the routing of the letsencrypt container) returns an empty string as the first match. You then send an XHR to check if that url exists or not, which it always does for this particular nginx reverse proxy setup.
A workaround is to remove the try_files statement and replace it with return 404;, assuming you do not need that url for anything. The fix would be to correctly check whether or not the request is actually to a subfolder or not by filtering empty strings from the pathname after the split.
It works when accessed from the internet via reverse proxy, but does not work when accessed directly
I am having the exact same issue after upgrading to v4. Accessing it directly via hostname:port or IPaddress:port just gets stuck on loading screen with the rotating square. Accessing it via my reverse proxy on a public URL works just fine. This wasn't an issue before the upgrade from v3.
This is on a Windows 10 computer with Ombi running as a service.
Hopefully, you can take a look att kristanmres solution. There is something wrong with nginx/swag reverse proxy and subfolder setup. My fix now was to use the subdomain reverse proxy alternative as that works well with docker and nginx, probably because you are navigating from the root and not a subfolder which means that you avoid the subfolder problem.
Accessing it directly via hostname:port or IPaddress:port just gets stuck on loading screen with the rotating square. Accessing it via my reverse proxy on a public URL works just fine
This is currently expected behaviour and it's unfortunately how I've had to get things working. I have yet to find a good way to do this with the Angular frontend and doesn't seem like a common/supported scenario unfortunately.
I started having this issue recently as well. I had upgraded to v4 a month or two ago and migrated just fine from v3. Then I noticed the problem detailed in this ticket started happening a few days ago.
Similar to @joggs my temporary fix is to use a subdomain instead of path prefix. This is not ideal as I also use Organizr V2 in front of Ombi, which requires Ombi to be on a path of the same domain for SSO to work correctly.
What is strange is that I did get it working without a subdomain on my own instances of Chrome/Edge, but Firefox was broken. I had users start reporting that it was also broken for them on their Chrome, so I had to roll back to the subdomain fix. Maybe it depends on the Chrome version being used? Not quite sure why it would have been different...
I have the same issue, running ombi v4 in a docker container with nginx in the letsencrypt docker container. No problem with v3, only with v4. Can someone help?
I can confirm that this error is still present now. Running Ombiv4 docker image on a SSL reverse proxy and I will get a looped / infinite loading due to SyntaxError: expected expression, got '<'.
Accessing Ombi through local is not possible anymore for me as I strictly allow entries through HTTPS so my only solution can come with a patch or a re-installation of Ombi to an anterior version (which I kinda want to avoid right now).
Same issue. Upgraded from 3.0.3052 to 4.0.721 (windows).
Accessing via IP:Port via LAN, I get the "Loading UI"
Accessing via NGINX reverse proxy (WAN) loads without issue,
2020-11-22 17:54:41.036 -06:00 [Warning] could not read configuration using ConfigurationManager.GetSection: Configuration system failed to initialize
2020-11-22 17:54:41.131 -06:00 [Information] Default Quartz.NET properties loaded from embedded resource file
2020-11-22 17:54:41.283 -06:00 [Debug] TaskSchedulingThreadPool configured with max concurrency of 10 and TaskScheduler ThreadPoolTaskScheduler.
2020-11-22 17:54:41.291 -06:00 [Information] Initialized Scheduler Signaller of type: Quartz.Core.SchedulerSignalerImpl
2020-11-22 17:54:41.293 -06:00 [Information] Quartz Scheduler v."3.1.0.0" created.
2020-11-22 17:54:41.297 -06:00 [Information] RAMJobStore initialized.
2020-11-22 17:54:41.306 -06:00 [Information] Scheduler meta-data: Quartz Scheduler (v3.1.0.0) 'DefaultQuartzScheduler' with instanceId 'NON_CLUSTERED'
Scheduler class: 'Quartz.Core.QuartzScheduler' - running locally.
NOT STARTED.
Currently in standby mode.
Number of jobs executed: 0
Using thread pool 'Quartz.Simpl.DefaultThreadPool' - with 10 threads.
Using job-store 'Quartz.Simpl.RAMJobStore' - which does not support persistence. and is not clustered.
2020-11-22 17:54:41.306 -06:00 [Information] Quartz scheduler 'DefaultQuartzScheduler' initialized
2020-11-22 17:54:41.306 -06:00 [Information] Quartz scheduler version: 3.1.0.0
2020-11-22 17:54:41.309 -06:00 [Information] JobFactory set to: Ombi.Schedule.IoCJobFactory
2020-11-22 17:54:41.583 -06:00 [Information] Scheduler DefaultQuartzScheduler_$_NON_CLUSTERED started.
Fresh install with v4 yesterday and I am having the same issues but this is both local LAN and outside WAN.
Running Debian 9.13 (Stretch) using systemd service.
Whenever I even attempt to do something this is what I get.
2020-11-26 13:45:48.791 -05:00 [Error] StatusCode: Unauthorized, Reason: Unauthorized, RequestUri: https://plex.tv/users/sign_in.json
2020-11-26 13:45:48.791 -05:00 [Warning] Failed login attempt by IP: ::ffff:10.1.10.20
2020-11-26 13:46:06.649 -05:00 [Error] Something bad happened, ErrorMiddleware caught this
System.InvalidOperationException: Cannot return null from an action method with a return type of 'Microsoft.AspNetCore.Mvc.IActionResult'.
at Microsoft.AspNetCore.Mvc.Infrastructure.ActionMethodExecutor.EnsureActionResultNotNull(ObjectMethodExecutor executor, IActionResult actionResult)
at Microsoft.AspNetCore.Mvc.Infrastructure.ActionMethodExecutor.TaskOfIActionResultExecutor.Execute(IActionResultTypeMapper mapper, ObjectMethodExecutor executor, Object controller, Object[] arguments)
at Microsoft.AspNetCore.Mvc.Infrastructure.ControllerActionInvoker.<InvokeActionMethodAsync>g__Awaited|12_0(ControllerActionInvoker invoker, ValueTask`1 actionResultValueTask)
at Microsoft.AspNetCore.Mvc.Infrastructure.ControllerActionInvoker.<InvokeNextActionFilterAsync>g__Awaited|10_0(ControllerActionInvoker invoker, Task lastTask, State next, Scope scope, Object state, Boolean isCompleted)
at Microsoft.AspNetCore.Mvc.Infrastructure.ControllerActionInvoker.Rethrow(ActionExecutedContextSealed context)
at Microsoft.AspNetCore.Mvc.Infrastructure.ControllerActionInvoker.Next(State& next, Scope& scope, Object& state, Boolean& isCompleted)
at Microsoft.AspNetCore.Mvc.Infrastructure.ControllerActionInvoker.InvokeInnerFilterAsync()
--- End of stack trace from previous location ---
at Microsoft.AspNetCore.Mvc.Infrastructure.ResourceInvoker.<InvokeNextResourceFilter>g__Awaited|24_0(ResourceInvoker invoker, Task lastTask, State next, Scope scope, Object state, Boolean isCompleted)
at Microsoft.AspNetCore.Mvc.Infrastructure.ResourceInvoker.Rethrow(ResourceExecutedContextSealed context)
at Microsoft.AspNetCore.Mvc.Infrastructure.ResourceInvoker.Next(State& next, Scope& scope, Object& state, Boolean& isCompleted)
at Microsoft.AspNetCore.Mvc.Infrastructure.ResourceInvoker.InvokeFilterPipelineAsync()
--- End of stack trace from previous location ---
at Microsoft.AspNetCore.Mvc.Infrastructure.ResourceInvoker.<InvokeAsync>g__Awaited|17_0(ResourceInvoker invoker, Task task, IDisposable scope)
at Microsoft.AspNetCore.Routing.EndpointMiddleware.<Invoke>g__AwaitRequestTask|6_0(Endpoint endpoint, Task requestTask, ILogger logger)
at Swashbuckle.AspNetCore.SwaggerUI.SwaggerUIMiddleware.Invoke(HttpContext httpContext)
at Swashbuckle.AspNetCore.Swagger.SwaggerMiddleware.Invoke(HttpContext httpContext, ISwaggerProvider swaggerProvider)
at Microsoft.AspNetCore.Authorization.Policy.AuthorizationMiddlewareResultHandler.HandleAsync(RequestDelegate next, HttpContext context, AuthorizationPolicy policy, PolicyAuthorizationResult authorizeResult)
at Microsoft.AspNetCore.Authorization.AuthorizationMiddleware.Invoke(HttpContext context)
at Microsoft.AspNetCore.Authentication.AuthenticationMiddleware.Invoke(HttpContext context)
at Ombi.ApiKeyMiddlewear.Invoke(HttpContext context)
at Ombi.ErrorHandlingMiddleware.Invoke(HttpContext context)
In my case, I cannot access from WAN. LAN works ok, given that I'm using a subdomain instead of a base URL.
No changes to my config from v3 to v4.
Looking at the above info, it seems that the issue is related to folks that have the base URL set, which is not my case. Any guidance?
Tried everything mentioned above , but still see white page, or sometimes the login screen and I cannot continue, or even I did see loops..
My root / folder is running Heimdall, so cannot use that for Ombi. I use Ombi in a docker and run Nginx directly from the host.
I also have /radarr / sonarr / /tautulli and more running, so this should not be too difficult.
my docker has the BASE_URL=/ombi and the app itself in the settings I mentioned /ombi
The above mentioned commend:
In src/Ombi/ClientApp/src/index.html line 15 you split the pathname by a forwardslash, which for a subfolder (ending with a forwardslash also as per the routing of the letsencrypt container) returns an empty string as the first match. You then send an XHR to check if that url exists or not, which it always does for this particular nginx reverse proxy setup.
is that fixed already?
No.
Thanks.
Tried your change for NGINX to have return 404; but didn't do the trick for me. For the time being will use the non proxied option but a real fix would be great :) as mentioned all my other apps work just fine.
In my case, I cannot access from WAN. LAN works ok, given that I'm using a subdomain instead of a base URL.
No changes to my config from v3 to v4.
Looking at the above info, it seems that the issue is related to folks that have the base URL set, which is not my case. Any guidance?
My issues if now fixed. It looks like I was missing the API and Swagger location blocks in my NGINX conf. That was the only change I did and it started working :)
Most helpful comment
The problem with the baseurl is with the entrypoint html's javascript and how linuxserver has built their swag/letsencrypt container.
By default the linuxserver's letsencrypt nginx is configured to return the nginx/www/index.html for the default "/" location -- see site-confs/default, root is set to config/www, which corresponds to your conf/nginx/www folder and location / block is set to try_files /index.html among others.
In src/Ombi/ClientApp/src/index.html line 15 you split the pathname by a forwardslash, which for a subfolder (ending with a forwardslash also as per the routing of the letsencrypt container) returns an empty string as the first match. You then send an XHR to check if that url exists or not, which it always does for this particular nginx reverse proxy setup.
A workaround is to remove the try_files statement and replace it with return 404;, assuming you do not need that url for anything. The fix would be to correctly check whether or not the request is actually to a subfolder or not by filtering empty strings from the pathname after the split.