Webui is gone, need help to reinstall

Issue Description

When trying to access /admin or /account all I see is
{“type”:“about:blank”,“status”:404,“title”:“Not Found”,“detail”:“The requested resource does not exist on this server.”}

The webui is gone, probably because after migrating to 0.16, the default path is /tmp once again and it got wiped.

Expected Behavior

I can access the webui.

Actual Behavior

I see a 404

Reproduction Steps

install stalwart
wait a day (/tmp gets cleared every day)
try to access webui

Stalwart Version

v0.16.x

Installation Method

Binary (Linux)

Database Backend

RocksDB

Blob Storage

RocksDB

Search Engine

Internal

Directory Backend

LDAP

Additional Context

I really need a step-by-step guide on how to rebuild/reinstall the webui, so I can access the admin page again.
I couldn’t find a single working manual on the internet and ai is also of no use.
The virtual machine has internet access, so no issue on downloading the webui here.
And it also doesn’t seem to auto heal or whatever.

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

Let me look up the documentation on WebUI installation and configuration.

This is a two-part problem, and the fix depends on whether you can still authenticate via the JMAP API (e.g. with stalwart-cli or curl).


What happened

The WebUI is not bundled with the Stalwart binary. It’s a hosted Application object that gets downloaded from GitHub and unpacked to a local directory. The unpackDirectory field on the Application record defaults to /tmp when left empty – and /tmp is typically cleared on reboot or daily by the OS. That’s exactly your situation: the bundle got wiped and nothing re-downloaded it because autoUpdateFrequency defaults to 90d.


The fix: update the unpackDirectory and force a re-download

You need to do two things:

1. Set a persistent unpackDirectory

Update the WebUI Application record to use a stable path (e.g. /var/lib/stalwart/webui) instead of the default /tmp. Do this via the JMAP API using curl (replace YOUR_TOKEN, YOUR_APP_ID, and mail.example.com):

First, find the Application ID:

curl -X POST https://mail.example.com/api \
  -H 'Authorization: Bearer YOUR_TOKEN' \
  -H 'Content-Type: application/json' \
  -d '{
    "methodCalls": [["x:Application/get", {}, "c1"]],
    "using": ["urn:ietf:params:jmap:core", "urn:stalwart:jmap"]
  }'

Then update it (replace YOUR_APP_ID with the id from above):

curl -X POST https://mail.example.com/api \
  -H 'Authorization: Bearer YOUR_TOKEN' \
  -H 'Content-Type: application/json' \
  -d '{
    "methodCalls": [["x:Application/set", {
      "update": {
        "YOUR_APP_ID": { "unpackDirectory": "/var/lib/stalwart/webui" }
      }
    }, "c1"]],
    "using": ["urn:ietf:params:jmap:core", "urn:stalwart:jmap"]
  }'

Make sure that directory exists and is writable by the stalwart service user:

mkdir -p /var/lib/stalwart/webui
chown stalwart:stalwart /var/lib/stalwart/webui

2. Force an immediate re-download

Trigger an UpdateApps action via the JMAP API:

curl -X POST https://mail.example.com/api \
  -H 'Authorization: Bearer YOUR_TOKEN' \
  -H 'Content-Type: application/json' \
  -d '{
    "methodCalls": [["x:Action/set", {
      "create": { "new1": { "@type": "UpdateApps" } }
    }, "c1"]],
    "using": ["urn:ietf:params:jmap:core", "urn:stalwart:jmap"]
  }'

This instructs the server to immediately re-download the WebUI bundle from https://github.com/stalwartlabs/webui/releases/latest/ and unpack it to the new persistent directory. After that, /admin and /account will be back up.


If you can’t get a token (because you have no WebUI and no prior token), you can also use stalwart-cli if it’s installed on the server – it can authenticate directly. Let us know and a community member can help with those specific CLI commands.

References: WebUI overview · Application object reference · Application updates

This is an automated reply from the Stalwart Help Bot. Other community members may follow up if this answer is incomplete or wrong.

Yes, i need the stalwart-cli way

in theory, just restarting stalwart should fetch/refresh the webui/http-applications, didn’t it?

Claude’s answer for me:

First get its id (one WebUI app, prefixes /admin+/account):

stalwart-cli query Application

Then, with :

  1. Refresh webui now (force redownload, bypass schedule) — UpdateApps Action:
    stalwart-cli create Action/UpdateApps
    No fields. Refreshes every enabled Application in one run — can’t scope to one. Downloads from resourceUrl, unpacks, hot-swaps live mount. Disabled apps skipped.

  2. Change extraction/unpack directory — unpackDirectory (default /tmp):
    stalwart-cli update Application --field unpackDirectory=/var/lib/stalwart/webui
    This is exactly the /tmp noexec / tmp-cleared fix. Dir must exist + be exec-able by stalwart. Takes effect next refresh — pair with create Action/UpdateApps to re-unpack immediately.

  3. Shorten refresh to 7d — autoUpdateFrequency (Duration, default 90d):
    stalwart-cli update Application --field autoUpdateFrequency=7d

Note: WebUI bundle pulls from github.com/objects.githubusercontent.com on 443 — shorter interval = more frequent egress. Fine if host has outbound HTTPS.

Would be nice if stalwart-cli worked over a UNIX socket rather than HTTP API

Every time I try to use stalwart-cli it says:
error: jmap error: forbidden: You are no authorized to perform this action

Even though the account I use for the environment variables are correct.

If the Web UI works, the CLI also works. They use the same way to connect. You need to pass the correct arguments, though.

It somehow worked now with my own ldap-synced account to modify and redownload the webui