I upgraded from 0.15x to 0.16.13 following the upgrade instructions on Github.
But one thing I forgot is that I had put a watchdog to restart Stalwart in case it hangs, due to this discussion:
So during the upgrade, after I stopped the service, the watchdog I placed kicked in and started Stalwart back in about 2-3 minutes, without me noticing it. Then when I tried to start the new binary in recovery mode, it complained that something was already listening on port 8080. Then I realized it and killed back the respawned process and finished the upgrade process with no further errors.
I don’t know if it is relevant with this mistake but;
Right now, JMAP endpoints return HTTP 404 in a JSON object when queried. So Oauth does not work. When I check Network → HTTP → Security, “Allowed endpoints” list is empty. Should the default endpoints be here? If yes, then how do I add them back?
By the way, Email → Defaults → Default Folders were also empty; I added the default list by selecting and configuring them from the list one by one. I don’t know if they should have already been there.
I understand that topics in this category are triaged by a bot first but a human reply will follow up. If I’d prefer a human-only reply, I’ll add the no-ai tag to my topic.
Both fields you found empty have documented, non‑empty defaults, so what you’re seeing is not the normal factory state:
allowedEndpoints on the Http singleton (Network › HTTP › Security) defaults to the expression {"else": "200"}, meaning “allow every endpoint.” If the WebUI shows this as completely empty/blank rather than that default rule, it’s not evaluating to an always‑allow expression, which would explain your JMAP/OAuth 404s (a rule with no matching condition and no else clause denies by default). See Http.allowedEndpoints and the HTTP Access Control guide.
defaultFolders on the Email singleton is meant to be pre-populated with the standard special-use folders (inbox, trash, junk, drafts, sent, etc.) — see Email.defaultFolders and the example in the IMAP settings doc.
Both being empty at once strongly suggests a config write got interrupted or clobbered, most likely from the old 0.15 process and the freshly started 0.16 binary briefly running against the same store simultaneously during your watchdog’s respawn, causing a partial or racy write to the settings objects. That’s consistent with your timeline (two processes contending for port 8080 right when the config would have been migrated/written).
To fix it, the safest path is what you already did for folders: explicitly set the fields back through the WebUI (Network → HTTP → Security → Allowed endpoints, and Email → Defaults → Default Folders), using the documented default values as your template, or apply them via stalwart-cli against the Http and Email singletons. I’d also recommend checking other core singletons (e.g. Network → HTTP general settings, listeners) for similar unexpected blanks, since the same race could have affected more than these two objects.
This is an automated reply from the Stalwart Help Bot. Other community members may follow up if this answer is incomplete or wrong.
Allowed endpoint is empty but “Else” box reads “200”. Shouldn’t this be already meaning “Allow everything”? Because it looks like the exact default you said: {"else": "200"}. So it should be empty then, other than this little rule? Then why would /auth endpoints return JSON objects saying HTTP 404 within?
Secondly, “HTTP Access Control” guide says the rules could be managed under HTML → Access Control, but my UI shows only General, Security, Contact Form tabs, nothing more, no ACL here. Could it be that the documentation is not refreshed for version 0.16? Is ACL still relevant in this version?
The empty “Allowed endpoints” list with Else set to 200 is the correct default: it means allow everything, so there’s nothing to populate there and it isn’t what’s causing your 404s. Your own reasoning on that was right.
The 404s are the same thing as in your other thread: /auth/* and /jmap only accept POST (and JMAP needs authentication), so a browser GET falls through to a 404. It isn’t upgrade damage. The one genuine issue is a docs one: the HTTP Access Control page still points at an “Access Control” tab that doesn’t exist in 0.16; the allowed-endpoints ACL now lives under Network > HTTP > Security > Allowed endpoints. I’ll get that page updated. The empty default folders after the upgrade are cosmetic (defaults are applied at account creation, so an existing account won’t show them retroactively); re-adding them as you did is harmless.
Thank you, I can see that it is the default already so there’s no problem in the configuration, so I will mark this as solved. But OAuth is still not working, which I am discussing on another thread already. By the way, I will still have this fresh installation persist rather than restoring the old backup; since there’s still something wrong in the backup because for example it never populates logs although it has the log file settings correctly. And since I don’t know what more it could have broken while the process started earlier than it should, during the upgrade process, I decided to start over with fresh default config.
