WebDav stopped functioning

Questions
1

Your question

I am running into an issue, but it is not one I can reproduce.

My WebDav server that I have been using for some time and was functioning well stopped working. Now, when I try to access my files I am still able to successfully authenticate, but after authentication the connection drops. Nginx returns me a 502 error and I see the following in nginx logs:

[error] 80704#80704: *1 upstream prematurely closed connection while reading response header from upstream...

Stalwart logs:

2026-08-08T05:29:00Z DEBUG HTTP connection started (http.connection-start) listenerId = "https", localPort = 443, remoteIp = 172.18.0.1, remotePort = 47724
2026-08-08T05:29:00Z DEBUG HTTP request URL (http.request-url) listenerId = "https", localPort = 443, remoteIp = 172.18.0.1, remotePort = 47724, url = "/dav/file/mail"
2026-08-08T05:29:00Z TRACE Expression evaluation result (eval.result) listenerId = "https", localPort = 443, remoteIp = 172.18.0.1, remotePort = 47724, id = "Http with id singleton", key = "allowedEndpoints", result = "Integer(200)"
2026-08-08T05:29:00Z DEBUG Cache hit (store.cache-hit) key = 2, collection = "accessToken"
2026-08-08T05:29:00Z TRACE HTTP request body (http.request-body) listenerId = "https", localPort = 443, remoteIp = 172.18.0.1, remotePort = 47724, details = [["host", "<domain>"], ["x-real-ip", "<ip>"], ["x-forwarded-for", "<ip>"], ["x-forwarded-proto", "https"], ["connection", "close"], ["content-length", "288"], ["user-agent", "cadaver/0.28 neon/0.37.1"], ["depth", "0"], ["content-type", "application/xml"], ["authorization", "Basic <redacted>"]], contents = "<?xml version="1.0" encoding="utf-8"?>\n<propfind xmlns="DAV:"><prop>\n<getcontentlength xmlns="DAV:"/>\n<getlastmodified xmlns="DAV:"/>\n<executable xmlns="http://apache.org/dav/props/"/>\n<resourcetype xmlns="DAV:"/>\n<checked-in xmlns="DAV:"/>\n<checked-out xmlns="DAV:"/>\n</prop></propfind>\n", size = 288
2026-08-08T05:29:00Z DEBUG Cache hit (store.cache-hit) key = "<domain>" collection = "domainName"
2026-08-08T05:29:00Z DEBUG Cache hit (store.cache-hit) key = 3, collection = "domainId"
2026-08-08T05:29:00Z DEBUG Cache hit (store.cache-hit) key = "mail", domain = 3, collection = "email"
2026-08-08T05:29:00Z TRACE Data store iteration operation (store.data-iterate) elapsed = 0ms
2026-08-08T05:29:00Z DEBUG Cache hit (store.cache-hit) key = 2, collection = "account"
2026-08-08T05:29:00Z TRACE Data store iteration operation (store.data-iterate) elapsed = 0ms

There doesn’t seem to be any failures listed in the logs.

The stalwart CardDav and CalDav servers are still functioning, so I think this has to be an issue specific to the WebDav instance. I don’t have any important files stored in this, so I don’t mind resetting the WebDav instance if needed. Is it possible to reset just the WebDav?

Stalwart version: 0.16.x (Docker), using RocksDB for database engine and blob storage.

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.

2

The silence is the useful part here. Every store operation is instrumented, so a request that logs the resource fetch and then just stops, with the socket closed and no error event, is almost certainly a panic in the connection task rather than a rejection. Panics go to stderr and never reach the Stalwart log, which is exactly why your trace shows no failure at all.

Could you restart the container with RUST_BACKTRACE=1 in the environment, reproduce, and then grab docker logs <container> 2>&1 | tail -50? That’s the one artifact that turns this into something I can fix. Also useful: whether the process stays up or restarts, whether a plain <allprop/> PROPFIND at Depth 0 behaves the same as cadaver’s named-prop request, and whether the same account works through the web UI’s file browser. CalDAV and CardDAV surviving is consistent with a panic rather than a config problem, since the file collection has its own property set and its own quota resolution that the calendar and contact collections don’t go through.

On resetting: there’s no command for it. stalwart-cli only manages configuration objects, not per-account DAV data, so the only route is deleting the collections over WebDAV or destroying the nodes over JMAP, and both of those need the account reachable in the first place. I’d get the backtrace before wiping anything, since wiping takes the evidence with it and this looks reproducible.

3

When I reproduce the issue the following is printed in the log
```

thread ‘tokio-rt-worker’ (8) panicked at crates/groupware/src/cache/file.rs:112:43:
called Option::unwrap() on a None value
stack backtrace:
note: Some details are omitted, run with RUST_BACKTRACE=full for a verbose backtrace.

```

The stalwart process seems to stay up.

I tried doing the <allprop/> PROPFIND at Depth 0 and it resulted in the same panic shown above.

4

Fixed in v0.16.18 (yet to be released).