shardpostctl-account(1)

account show

Answers the question "does this account exist, and what does the server see?" in one place:

lookup

What the user database (Nauthilus) says about the name you passed: canonical (this is the account itself), alias (with the canonical account it belongs to), unknown or unavailable (the directory did not answer). Most support cases end here, because the name in the ticket is an alias or a typo.

store

Whether the account has data in the store, and how many mailboxes.

quota

Usage and limit, in bytes and messages.

import lock

Whether an import or a maintenance job currently holds the account. While it does, IMAP, POP3 and LMTP refuse the account on purpose.

trace

Whether a protocol trace is switched on; see shardpostctl-trace(1).

The account must be given in its canonical form; an alias is reported as such but is not followed.

quota show

Usage and limit only. The limit comes from the user database (the LDAP attribute in the operating profile), the usage from the store's counters. If the two look implausible, recount them with the quota_recalc job; see shardpostctl-job(1).

quota online status

Shows whether the cluster mark of online quota recounts (quota/online, since 0.52.0) is set, with the server registrations as fts layout3 status shows them. The mark allows quota_recalc to run without the account lock: the writers capture every change of the usage while the run counts, and one compare-and-swap switches the counters; deliveries, logins and sessions go on. A server before 0.52.0 does not capture, so the counters a run switched to would be wrong (a following run corrects them; no mail is lost): the mark needs every server to know it. Without the mark every run is offline under the account lock, as before 0.52.0. Role: diagnose.

quota online enable

Sets the mark when exactly n fresh registrations of servers report the capability quota_online_recount; otherwise it is refused with exit code 65 naming the instances. -force sets it without the check (audited). Plans with -online are allowed from then on, and with quota.online_recount: auto also plans without it. Role: repair.

quota online disable

Removes the mark: new plans run offline, a plan with -online is refused. Runs that started finish or end busy; before a downgrade to a version before 0.52.0 wait for them (or cancel the jobs, which clears their run keys). Role: repair.

shared list

Lists the mailboxes of other accounts this account was granted rights on, as the client sees them under the shared prefix (server.shared_prefix, by default Shared/). For the other direction (who may see this account's mailboxes) use shardpostctl-acl(1).

These three commands require the role diagnose.

account directory

Shows the account's entry in the account directory, the store-wide list of accounts:

entry

active or purging (with the lock session of the purge job), or no entry.

created

When the account was last created (its registry; for accounts the backfill entered, the registry's last change).

registry

Whether the account's data still exists (its registry object).

directory

Shard count and phase of the directory.

last scrub

When the last batch scrub of the account ended, whether it was complete and how many findings it had; see plan -all -skip-idle scrub in shardpostctl-job(1).

backfill

The completion marker of the last shardpost index backfill accounts (start, end and counts as JSON), or none.

The account is not looked up in the user database. The command requires the role diagnose.

account list

Lists the account directory: every account that has data in the store, and the public namespace, with its state, when it was created and its last batch scrub. The directory is read page by page in its own order (shard, then account), not alphabetically; it is never a listing of the storage pool. A page holds -limit accounts (100 by default, at most 1000); the line more: names the cursor that -after continues with, and -all fetches every page, printing each one as it arrives. -state keeps only the entries in that state; such a page may hold fewer accounts while more follow. With --json a page prints as one document; with -all and --json every entry prints as one JSON line, so a large directory is never held in memory. The command requires the role diagnose and the scope of all accounts: socket callers have it, mutual-TLS clients only with all_accounts in their configuration.

account repair

Repairs the account's entry in the account directory, the store-wide list of accounts. The purge job marks an account purging before it deletes it and removes the entry at its end; while the mark is there and the account's data is gone, nothing can create the account again. A purge that failed or was cancelled in between leaves the mark behind, and the account stays unusable. The repair applies these rules:

purge_running

A purge job of the recorded lock session is still queued or running (another server may continue it): nothing is changed. Wait for the job or cancel it; see shardpostctl-job(1).

removed

The account was purging and its data is gone: the entry is removed, and the name can be used again.

activated

The account was purging but its data still exists (the purge stopped before it deleted the registry): the entry is active again.

stale_removed

The entry is active, older than ten minutes, and the account's data is gone: the entry is stale (a purge by an older server version, a crash between the entry and the creation of the account) and is removed.

none

Anything else: nothing to do.

The output shows the action and the state before and after. The account is not looked up in the user database, since a purged account may no longer exist there. The command requires the role repair. The backfill (shardpost index backfill accounts) applies the same rules to every account.

While an account is left purging by a purge that ended, no other maintenance job can lock it — a second purge included. Such a job fails at once with "run shardpostctl account repair"; run the repair first, then plan the job again.