0.15.5 -> 0.16.3 - Account disk usage displayed incorrectly

tatodorov · May 8, 2026, 8:31am

Issue Description

After a successful upgrade from 0.15.5 to 0.16.3, when I go to Accounts → and scroll down to Details, Disk Usage displays wrong information.
Immediately after the migration it displayed 0 bytes, while all emails for that account were migrated and their actual disk usage is around 14 GB.
Also, just for test, I sent an email to that account from Proton, and the disk usage afterwards became few kilobytes.
Now it is even negative -40144 B.

For the upgrade from 0.15.5 to 0.16.3, I’ve been following these steps:

github.com/stalwartlabs/stalwart

UPGRADING/v0_16.md

main

# Upgrading from `v0.15.x` to `v0.16.x`

Stalwart `v0.16.x` introduces **significant breaking changes** that make its configuration and management layer **completely incompatible** with every previous release. The database layout used to store user data (emails, calendars, contacts, files, blobs, search indexes) is **not** affected by this change, so message bodies, mailboxes, calendar events, and shared files remain on disk unchanged. What does change is **how the server is configured and managed**, and because those records live inside the same database, a multi-step migration is required.

Before continuing, please read this document in full. Skipping steps will leave the server in an unrecoverable state and will require restoring from a backup.

If any step below raises questions, a dedicated discussion thread for the `v0.16` upgrade is open at https://support.stalw.art. The earlier design discussion that led to these changes is also public at https://github.com/stalwartlabs/stalwart/discussions/2892 and describes the user-reported problems that motivated each breaking change.

## A note on downtime

Email is a critical service, and we understand that a forced maintenance window is disruptive:  in some environments it is simply not an option. The breaking changes in `v0.16` are not cosmetic. Stalwart has been under continuous development for close to five years; in that time the feature set and the user base have both grown well beyond what the original configuration and management layer was designed for. The gap between what users need and what the old architecture can cleanly support has widened to the point where a redesign was unavoidable:  and the redesign itself unlocks a long list of frequently-requested features that were simply not implementable under the previous model. The storage layer is untouched by all of this: emails, calendars, contacts, files, and every other piece of user data stay exactly where they are. The migration is about configuration, not about data.

Operators who cannot accept downtime should **wait**. In the next two to three weeks we plan to release two tools that work together:

- A **zero-downtime migration utility** that moves data (accounts, mailboxes, calendars, contacts, files) from an existing (`v0.15.x` or below) deployment to a freshly-installed `v0.16.x` deployment one account at a time, while both servers are running.
- A **proxy** that sits in front of both deployments and routes each incoming connection to the server that currently owns that account. As accounts are migrated one by one, the proxy transparently shifts their traffic from the old deployment to the new one, so end users never notice a cutover.

Together, these let operators migrate a live production deployment on an account-by-account basis with no scheduled maintenance window. When those tools are available, the instructions in this document will be superseded for most deployments. Everyone else can follow the manual steps below during a scheduled maintenance window.

## What has changed

This file has been truncated. show original

Expected Behavior

The disk usage per account should reflect the usage of all emails, from before the upgrade to 0.16 and after.

Actual Behavior

Seems the the disk usage reflects only the emails received after the upgrade to 0.16.
Though, there was a time when the usage was also negative.

Relevant Log Output

I don’t see any logs related to the disk usage.

Stalwart Version

v0.16.x

Installation Method

Built from source

Database Backend

PostgreSQL

Blob Storage

PostgreSQL

Search Engine

PostgreSQL

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

helpbot · May 8, 2026, 8:31am

This is a known post-migration step that was missed. From the v0.16 upgrade guide (UPGRADING/v0_16.md):

Disk quotas were reset to zero during the wipe and need to be rebuilt from the actual mailbox contents.

The fix is straightforward:

Log in to the admin WebUI.
Navigate to the Tasks section.
Trigger the “Recalculate disk quotas” task.

This spawns one subtask per user account. Each subtask scans that user’s actual mailbox storage and updates the usage counter. On a large deployment (e.g. 14 GB of mail) it may take a while — progress is visible in the Tasks panel. Once it completes, the displayed disk usage should be accurate.

The negative value you’re seeing is a side-effect of incremental writes (new mail arriving) being applied on top of a zero baseline before recalculation has run — that’s expected to resolve once the recalculation task finishes.

For reference, this step is described in the v0.16 upgrade guide under “Post-migration tasks → Recalculate disk quotas”.

This is an automated reply from the Stalwart Help Bot. Other community members may follow up if this answer is incomplete or wrong. If you found it useful, mention @helpbot in any reply to ask follow-up questions and the bot will respond again.

tatodorov · May 8, 2026, 9:04am

Indeed, the issue was resolved by creating a task to recalculate the storage.

This is how to do it for a single tenant deployment:

Management → Tasks → Scheduled → Create task

Task type: Perform account maintenance operations
Account: <SELECT_A_SPECIFIC_ACCOUNT>
Maintenance Type: Recalculate storage quota usage for the account

A separate task needs to be created for each account.

When we set “Task type” to “Perform tenant maintenance operations”, we must select a tenant.
In single tenant deployment, we can’t select a tenant.

helpbot · May 8, 2026, 9:04am

Great news that it’s resolved! Thank you for posting the exact steps for a single-tenant deployment — that’s a helpful clarification that the per-account maintenance task is the right path when there’s no tenant to select. This will be useful for others hitting the same issue after a migration.

This is an automated reply from the Stalwart Help Bot. Other community members may follow up if this answer is incomplete or wrong. If you found it useful, mention @helpbot in any reply to ask follow-up questions and the bot will respond again.

Topic		Replies	Views
Mail missing after migration to 0.16 Issues	7	181	June 7, 2026
Allow using IP and http for admin webui Issues	2	22	June 12, 2026
Moving emails and user data (calendar etc) to new server Questions	2	27	June 10, 2026
0.15 → 0.16 upgrade silently enters bootstrap mode (Docker, existing config + data not detected) Issues	4	111	May 25, 2026
Admin login after upgrade to v16 Questions	2	67	May 17, 2026

0.15.5 -> 0.16.3 - Account disk usage displayed incorrectly

Issue Description

Expected Behavior

Actual Behavior

Relevant Log Output

Stalwart Version

Installation Method

Database Backend

Blob Storage

Search Engine

Directory Backend

I have reviewed the documentation and FAQ and confirm that my issue is NOT addressed there.

I have searched this support forum (open and closed topics) and confirm this is not a duplicate.

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.

Related topics