Issue Description
Prior v0.13.x installation asks for FQDN, but it is not the same anymore after the installation is complete. The DNS A record pointing to the server is not working.
Expected Behavior
Work out of the box asking for domain name during installation
Actual Behavior
Using the IP:8080/admin works but after the configuration and the server is rebooted, this error is diplayed in the UI {“type”:“about:blank”,“status”:404,“title”:“Not Found”,“detail”:“The requested resource does not exist on this server.”}
Stalwart Version
v0.16.x
Installation Method
Binary (Linux)
Database Backend
RocksDB
Blob Storage
S3-compatible
Search Engine
Internal
Directory Backend
Internal
I have reviewed the documentation and FAQ and confirm that my issue is NOT addressed there.
on
I have searched this support forum (open and closed topics) and confirm this is not a duplicate.
on
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.
on
The {"type":"about:blank","status":404,...} error after reboot is almost certainly caused by the WebUI bundle not being downloaded. Here is what is happening and how to fix it:
Root cause: The WebUI is not bundled in the binary. On first start, Stalwart fetches the WebUI bundle from https://github.com/stalwartlabs/webui/releases/latest/. If that download fails (e.g. the server can’t reach GitHub over HTTPS at startup time, or the initial setup via IP:8080/admin completed before the bundle was fully fetched), every /admin route returns 404 Not Found.
Steps to resolve:
- Verify outbound connectivity – confirm the server can reach
github.com and objects.githubusercontent.com on TCP/443:curl -I https://github.com/stalwartlabs/webui/releases/latest/
- Restart the service once connectivity is confirmed. Stalwart will re-attempt the bundle download on start.
- Access via
http://<IP>:8080/admin (not the hostname/FQDN) while TLS is still being set up. The FAQ notes that using the FQDN over HTTP can fail at the OAuth callback – the IP:8080 path is specifically exempt from that check.
- Regarding the FQDN/DNS A record not working: After the setup wizard, you need to make sure the DNS A record for your hostname is resolving correctly and that you are accessing
/admin over HTTPS using that hostname (once a certificate is provisioned). Accessing by IP on port 8080 is the correct approach during initial setup.
The FAQ covers this scenario in detail: FAQ - Why does /admin return 404 Not Found?
This is an automated reply from the Stalwart Help Bot. Other community members may follow up if this answer is incomplete or wrong.
Thank you this helped.
Successfully installed.
I’m trying to use Bulwark and getting this error
The server is reachable but is blocking cross-origin requests. Check your JMAP server's CORS settings and allow this domain.
I tried to turn it on, but it is not working.
Settings → Network → HTTP → Security
Permissive CORS policy
The “Permissive CORS policy” toggle maps to the usePermissiveCors setting, and that’s applied into the response headers when the config is loaded, so it takes effect after a settings reload, not just on save. Reload settings and try Bulwark again.
If it still complains, check where Bulwark is actually pointed and that the CORS header is present on the response:
curl -i -X OPTIONS https:///.well-known/jmap
You want Access-Control-Allow-Origin: * in the output. If it’s missing, Bulwark is likely reaching a different listener or a reverse proxy in front is stripping the header, so tell me whether there’s a proxy and which URL Bulwark uses.
Reloading the settings resolved it.
Thank you.
Is there any settings I need to turn on for Contact, Calendar and Files to work in Bulwark?
For Contacts, Calendar and Files there’s no server-side switch to flip; they’re served over JMAP (and over CalDAV/CardDAV/WebDAV) by default for every account, so nothing needs enabling on the Stalwart side. If Bulwark isn’t showing them, it’ll be a client-side discovery or capability matter rather than a server setting.