🐛: Server reports error 500 on a weekly basis

[Arvyr]

What happened?

Hallo,

with stalwart-mail I'm hitting a problem every week it seems where I can't login anymore with the error shown below:

After a systemctl restart stalwart a login is possible again, until a couple of days later.

I've already reinstalled stalwart a couple of times, but that didn't solve the issue.

I'm using AlmaLinux 10 with stalwart-mail 0.13 (happened with version 11 and 12 also).
SELinux is permissive and firewall allowing traffic on all neccesary ports.

I run stalwart mail on an extra partition with 10G of space (only 4% are currently used)

How can we reproduce the problem?

.

Version

v0.13.x

What database are you using?

RocksDB

What blob storage are you using?

RocksDB

Where is your directory located?

LDAP

What operating system are you using?

Linux

Relevant log output

2025-08-06T06:22:54Z DEBUG HTTP request URL (http.request-url) listenerId = "https", localPort = 443, remoteIp = fddd:33::31, remotePort = 58475, url = "/"
2025-08-06T06:22:54Z TRACE Expression evaluation result (eval.result) listenerId = "https", localPort = 443, remoteIp = fddd:33::31, remotePort = 58475, id = "http.allowed-endpoint", result = "Integer(200)"
2025-08-06T06:22:54Z ERROR Resource error (resource.error) listenerId = "https", localPort = 443, remoteIp = fddd:33::31, remotePort = 58475, reason = "No such file or directory (os error 2)", path = "", causedBy = "crates/common/src/manager/webadmin.rs:62"
2025-08-06T06:22:54Z TRACE HTTP response body (http.response-body) listenerId = "https", localPort = 443, remoteIp = fddd:33::31, remotePort = 58475, contents = "{"type":"about:blank","status":500,"title":"Internal Server Error","detail":"There was a problem while processing your request. Please contact the system administrator if this problem persists."}", code = 500, size = 195
2025-08-06T06:22:54Z DEBUG HTTP request URL (http.request-url) listenerId = "https", localPort = 443, remoteIp = fddd:33::31, remotePort = 58475, url = "/favicon.ico"
2025-08-06T06:22:54Z TRACE Expression evaluation result (eval.result) listenerId = "https", localPort = 443, remoteIp = fddd:33::31, remotePort = 58475, id = "http.allowed-endpoint", result = "Integer(200)"
2025-08-06T06:22:54Z ERROR Resource error (resource.error) listenerId = "https", localPort = 443, remoteIp = fddd:33::31, remotePort = 58475, reason = "No such file or directory (os error 2)", path = "favicon.ico", causedBy = "crates/common/src/manager/webadmin.rs:62"
2025-08-06T06:22:54Z TRACE HTTP response body (http.response-body) listenerId = "https", localPort = 443, remoteIp = fddd:33::31, remotePort = 58475, contents = "{"type":"about:blank","status":500,"title":"Internal Server Error","detail":"There was a problem while processing your request. Please contact the system administrator if this problem persists."}", code = 500, size = 195

Code of Conduct

• I agree to follow this project's Code of Conduct

[mdecimus]

You seem to have a permissions issue in the directory where the webadmin is unpacked.

[Arvyr]

It's not a permission issue.
What I found out is that - as per security requirements - the /tmp directory gets wiped every day.
The default location for the webadmin package is however /tmp.

After changing this location to something else (is there a reason why it's not in the stalwart-mail installation directory?) and reinstalling/updating webadmin, everything was back up running.

I came across the change log of Debian 13 where they mention, that /tmp will be cleared regularly now too.(https://www.debian.org/releases/trixie/release-notes/issues.en.html#the-directories-tmp-and-var-tmp-are-now-regularly-cleaned)
So it might make sense to change the default location of the webadmin package of stalwart-mail also.

[mdecimus]

Stalwart by default uses the temp directory returned by this rust function: https://doc.rust-lang.org/std/env/fn.temp_dir.html

Wiping out the /tmp directory every day is a strange default behaviour, what Stalwart stores there is not critical but it might affect others programs that rely on temporary directories to process data. Do they at least check the file's last modification date or they simply wipe out the entire directory?

[Arvyr]

The cron job clears all data older than 24h.
I modified the script however to exclude systemd-private directories now, because that caused also issues with loggin in into freeipa's webgui.
How Debian 13 handles this is beyond my knowledge however.