gromox-mbop — Mailbox operations utility


gromox-mbop {-d mbox|-u} command [command-args...]

Global options

-d /var/lib/gromox/user/1/2

Lookup the mailbox parameters from the associated filesystem location.


Lookup the mailbox parameters from the associated username.


  • delmsg: issue "delete_message" RPCs for a mailbox

  • unload: issue the "unload_store" RPC for a mailbox

  • vacuum: issue the "vacuum" RPC for a mailbox



gromox-mbop -u delmsg -f folder_spec [msgid...]


This command hard-deletes messages from a store, including issuing proper PR_CHANGE_KEY metadata updates for the sake of Cached Mode clients.

The folder and message IDs taken as arguments on the command-line should be of the GC-value form, i.e. as they appear in the the SQLite database.

Subcommand options

-f folder_spec

The folder from which to delete the messages. See below for details. (If a msgid is specified which is not located in the particular folder, that message will not be deleted.)


Perform a soft deletion.



gromox-mbop -u emptyfld [-R] [--soft] folder_spec...


This command deletes messages from a folder.

Subcommand options


Besides messages, also delete subfolders.


Perform a soft deletion. (This feature is experimental.) Default is hard.


Normally, exmdb_provider(4gx) keeps stores open for up to exmdb_provider.cfg:cache_interval. The "unload_store" RPC to exmdb_provider(4gx) causes the sqlite database (in /var/lib/gromox/.../exmdb/exchange.sqlite3) to be closed. Any subsequent RPC may reopen it, though. The unload RPC is useful after a mailbox was deleted and/or reinitialized with grommunio-admin-api or tools like gromox-mkprivate(8)/gromox-mkpublic(8). [zcore also has store state in memory. This would also need to be purged — but there is no RPC for such action at this time.] unload will fail to succeed if there is still a client connected to the mailbox via a notification channel.


The "vacuum" RPC makes exmdb_provider issue the SQLite "vacuum" command on exchange.sqlite3, which rebuilds and compacts the database file.

Folder specification

folder_spec can either be a numeric identifier, or a path-like specification into the folder hierarchy. If the name starts with the slash character '/', it is interpreted as starting from the root; otherwise, the first component must be a special name (CALENDAR, COMMON_VIEWS, CONFLICTS, CONTACTS, DEFERRED_ACTION, DELETED, DRAFT, FINDER, INBOX, IPM_SUBTREE, JOURNAL, JUNK, LOCAL_FAILURES, NOTES, OUTBOX, SENT, SERVER_FAILURES, SHORTCUTS, SYNC_ISSUES, TASKS, VIEWS). These special names can be used with private stores only; there are no names defined for public folder contents at this time. There is also no parsing support for slashes in folder names currently in mbop; the slash character is always treated as a hierarchy separator. Examples:

  • /Top of Information Store/Sent Items/2022

  • IPM_SUBTREE/Sent Items/2022

  • SENT/2022

See also