When browsing to the server’s web page and logging in as an admin user, the message “Something went wrong. Failed to fetch dynamically imported module: https://[DOMAIN]/account/assets/AdminPanel-CJi_nYsw.js” appears along with a button marked “Try Again”. Clicking the button reloads the same page.
Expected Behavior
The normal welcome/dashboard page should be displayed to an admin user logging in.
Actual Behavior
The mail server (SMTP and IMAP) continues to operate correctly. The web page redirects to the “Something went wrong…” page.
Reproduction Steps
Unknown - this was working for over a week and on my return to the office it doesn’t work.
Restarting Stalwart has solved the problem and it is not currently reproducable, but this is clearly not a practical solution if it happens again.
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.
This confirms my understanding. Found the exact answer.
This matches your symptom exactly. Here’s what’s happening based on the docs and the source code:
The WebUI bundle is unpacked into a working directory on the local filesystem, chosen automatically under /tmp by default. If that directory is cleared, cleaned up by systemd-tmpfiles, or otherwise wiped out from under the running process (e.g. during maintenance, a package update, or an aggressive /tmp cleanup policy), the individual chunked asset files (like AdminPanel-CJi_nYsw.js) are removed from disk even though the server still thinks they’re there, since Stalwart only re-fetches/re-unpacks the bundle on its own schedule or when explicitly triggered. That produces exactly the “No such file or directory (os error 2)” error you saw, coming from application.rs, and the front-end shows “Failed to fetch dynamically imported module” because the browser can’t load the chunk.
To make this permanent-fix rather than restart-and-hope:
Pin a stable, non-volatile location with the unpackDirectory field on the Application record (found in the WebUI under Settings › Web Applications), instead of relying on the automatically chosen temp directory. This is specifically recommended for systems where /tmp is mounted noexec or cleared aggressively between restarts/service runs.
Once that’s set, trigger a fresh unpack (an UpdateApps action, or restart once) so the bundle is written to the new stable path.