System and Server Status interface not working at all

On latest Webmin/Virtualmin, in System and Server Status page, “Scheduled Monitoring” and “Edit Email Templates” buttons do not work.

The post requests both console return:

net::ERR_CONNECTION_RESET 200 (Document follows)

What’s expected: normal user interface reactions on these buttons, something similar to the interface shown in the documentation.

What’s happening: literally no/zero response from the interface, just spinning wheel

Webmin 1.981
Virtualmin 6.17-3	
Usermin 1.823
OS Ubuntu Linux 20.04.3
Browser: tried Chrome and Safari

N.B. Looks like someone else had this issue in May 2021 but no one responsed?

P.S. Postfix is turned off as I am using an external SMTP server for emails from Virtualmin, which is tested as working fine.

This seems to be related, that the “Scheduled Monitoring” button does not work for others too:

Screenshot here in case I wasn’t clear:

I can’t reproduce this on any browser I have. Maybe @Ilia has some ideas.

I have to assume it’s a problem with a cached version of the JavaScript bundle. Try clearing the cache, or opening in an incognito/private window.

1 Like

It seems to work for me either but I could login to your system and have a closer look.

1 Like

I’ve tried switching to the legacy grey theme and the interface works!

Switching back afterwards to the modern theme, though, and the issue persists.

At least for now there’s a workaround!

I’ve tried in incognito before.

Is there any chance when I upgraded webmin/virtualmin that a resource that should help serve the page is missing and I need to reinstall it?

Like I said before, it works for me. I have no idea what’s wrong.

Could you attach as a zip to this thread /etc/webmin/miniserv.conf and /etc/webmin/config files and /etc/webmin/status directory (or you could send it in a private message to me directly).

If I travel to navigate to that URL, I get a 404 not found on that CGI file?
Screenshot 2021-10-31 at 20.48.30

This means something, right?

No, that’s expected. There are URL rewrites happening in Authentic theme, that makes most direct URLs not work at all.

What do you mean, Joe?

There is webmin in URL, is this webprefix? If so, there were a lot of issue fixed for webprefix for upcoming release.

Oh, sorry, I tried hitting the URL he provided, but didn’t notice the prefix (and I also got a 404, assumed it was rewrites in Authentic, but I guess it’s not, just the XHR protection kicks in).

So…yeah, this is a prefix problem. @harryf you should really mention you’re proxying to Webmin, if you’re proxying to Webmin. A whole bunch of other stuff happens in a proxied connection.

I have fixed all issues with webprefix for upcoming Webmin release.

I will try installing current version to reproduce the issue.

1 Like

Hi folks,

No, I’m not proxying, I don’t believe. I thought I’d just try typing in the URL in your screenshot directly to see what response I get and as you said it’s expectably a 404.
Screenshot 2021-10-31 at 22.07.08

I have since tried Incognito with Disable Cache and the problem seems to be solved, which is too weird.

Never had this problem before with any webapp, and with any of the other modules on Webmin/Virtualmin.

I’m not sure what webprefix is in the Virtualmin context. I just have a basic vanilla Virtualmin install on Ubuntu.

Software has bugs, any software.

What Chrome version did you use?

Good point, yes. I tried Safari latest and Chrome latest on macOS latest.

I don’t understand, as earlier you mentioned that the issue was resolved, if you cleared cache? What Chrome and Safari versions did you try?

Yes, I agree, there is a contradiction there. There is no CloudFlare-level caching, for example. It’s direct :10000 to VirtualMin.

But “Disable Cache” in Chrome might have just been a coincidence. It works also now on Safari too.

Does disabling cache really worked or incognito mode, which also disabled all extensions loaded? Perhaps, the source of the problem was a browser extension?

Not sure.

There are no extensions in Incognito or in Safari. I think it was a server-side issue still, but it’s gone now and seems impossible to further investigate at this stage.