Overview
This guide shows, step by step, how to replace a public-folder-style shared structure in grommunio with a functional mailbox. The lab covered two domains in one organization, granular MAPI folder permissions, root and parent folder visibility, automatic mounting in grommunio Web, Send-As, an SMTP alias, and Thunderbird GUI evidence.
The article documents only what was technically tested in the lab. Thunderbird was tested with real GUI screenshots in an isolated X11 environment. Outlook and automatic inbox rules are marked as open until they have been reproduced separately.
Target setup
The test uses one organization with two domains. A classic public folder in domain A is not automatically a shared organization-wide workspace for users in domain B. For cross-domain shared folders inside one organization, the lab therefore used a normal functional mailbox.
Example Group├── example-a.test└── example-b.testshared-folders@example-a.test├── Finance├── Sales├── Projects│ ├── Project-A│ └── Project-B└── Shared
Tested baseline
The guide is based on an isolated grommunio Appliance 2026.06.1. Only neutral test data was used. No production customer data was involved.
Organization: Example GroupDomains: example-a.test, example-b.testUsers: alice@example-a.test, bob@example-b.testFunctional mailbox: shared-folders@example-a.testSMTP alias: finance@example-a.testCLI version: grommunio-admin 1.21.0+2Tools: grommunio-admin, gromox-mbop, jq, xxd, IMAP/SMTP test client, Playwright, Thunderbird 153.0.2
Replace the example values for your own PoC
All values below are neutral lab examples. For a customer PoC, replace them with your own test domains, users and functional mailbox. The command structure stays the same; the concrete names and the automatically discovered folder IDs will differ.
Prerequisites
You need administrative access to grommunio, shell access to the appliance, two domains in the same organization, at least two test users, and a separate functional mailbox. In production-like environments, run the procedure with neutral accounts first.
Step 1: Verify organization, domains and users
First verify that both domains belong to the same organization and that the test users exist. The lab used Example Group, example-a.test and example-b.test.
grommunio-admin org listgrommunio-admin domain listgrommunio-admin user list
The organization must contain both test domains. Otherwise the cross-domain test inside one organization is not meaningful.
The domain list shows example-a.test and example-b.test as active domains in the organization.
The user list shows Alice in example-a.test, Bob in example-b.test and the functional mailbox shared-folders@example-a.test. The SMTP alias finance@example-a.test belongs to the functional mailbox.
Step 2: Create the functional mailbox
The functional mailbox is a normal grommunio user mailbox, not a special public-folder type. That gives it its own folder tree, aliases and separate Send-As permissions.
grommunio-admin user create shared-folders@example-a.test \--domain example-a.test \--lang en_US \--pop3-imap true \--smtp true \--privWeb truegrommunio-admin passwd --password '<internal-test-password>' \shared-folders@example-a.testgrommunio-admin user modify shared-folders@example-a.test \--alias finance@example-a.testgrommunio-admin user show shared-folders@example-a.test
In the lab, the mailbox existed afterwards, had its own mailbox in example-a.test and listed finance@example-a.test as an alias. The password is intentionally not published.
Step 3: Create the folder tree
The folders were created with grommunio-admin exmdb in the store of the functional mailbox. The root ID in the lab was 0x9. Folder IDs can differ in other environments and should always be checked with folder list or folder find.
grommunio-admin exmdb shared-folders@example-a.test folder create Finance 0x9grommunio-admin exmdb shared-folders@example-a.test folder create Sales 0x9grommunio-admin exmdb shared-folders@example-a.test folder create Projects 0x9grommunio-admin exmdb shared-folders@example-a.test folder create Shared 0x9grommunio-admin exmdb shared-folders@example-a.test folder find Projects 0x9# Lab example: Projects received ID 0x1f0000.grommunio-admin exmdb shared-folders@example-a.test folder create Project-A 0x1f0000grommunio-admin exmdb shared-folders@example-a.test folder create Project-B 0x1f0000grommunio-admin exmdb shared-folders@example-a.test folder list -r
Expected result: Finance, Sales, Projects, Shared, and Project-A and Project-B below Projects appear in the recursive folder listing.
Step 4: Set folder visibility and working permissions
foldervisible is the path permission through the hierarchy. It makes a folder visible in the tree, but it does not by itself grant read or write access to other folders. For nested target folders, the root and all parent folders must be visible.
# Make the root visible without granting content access on root.grommunio-admin exmdb shared-folders@example-a.test folder grant \0x9 alice@example-a.test foldervisiblegrommunio-admin exmdb shared-folders@example-a.test folder grant \0x9 bob@example-b.test foldervisible# Alice may work in Finance.grommunio-admin exmdb shared-folders@example-a.test folder grant \0x1d0000 alice@example-a.test \readany create editowned deleteowned editany deleteany createsubfolder folderowner foldercontact foldervisible# Bob may work in Sales.grommunio-admin exmdb shared-folders@example-a.test folder grant \0x1e0000 bob@example-b.test \readany create editowned deleteowned editany deleteany createsubfolder folderowner foldercontact foldervisible# Bob may see the Projects parent folder.grommunio-admin exmdb shared-folders@example-a.test folder grant \0x1f0000 bob@example-b.test foldervisible# Bob may work in Project-A, but not Project-B.grommunio-admin exmdb shared-folders@example-a.test folder grant \0x210000 bob@example-b.test \readany create editowned deleteowned editany deleteany foldervisible
No StoreOwner or blanket delegate rights were granted in the lab. The design deliberately keeps the permissions limited to folder ACLs.
Step 5: Verify permissions
After setting permissions, the root, Finance, Sales, Projects, Project-A and Project-B were checked separately. The negative tests matter: users must see the expected folders, but folders without permission must remain inaccessible.
grommunio-admin exmdb shared-folders@example-a.test folder permissions 0x9grommunio-admin exmdb shared-folders@example-a.test folder permissions 0x1d0000grommunio-admin exmdb shared-folders@example-a.test folder permissions 0x1e0000grommunio-admin exmdb shared-folders@example-a.test folder permissions 0x1f0000grommunio-admin exmdb shared-folders@example-a.test folder permissions 0x210000grommunio-admin exmdb shared-folders@example-a.test folder permissions 0x220000grommunio-admin user storeowner shared-folders@example-a.test listgrommunio-admin user delegates shared-folders@example-a.test list
Lab result:Alice -> Finance: permission set, PASSAlice -> Sales: no permission set, PASSBob -> Sales: permission set, PASSBob -> Finance: no permission set, PASSBob -> Projects: foldervisible only, PASSBob -> Project-A: permission set, PASS via CLIBob -> Project-B: no permission set, PASSStoreOwner/Delegate: no blanket rights, PASS
Step 6: Mount the shared store in grommunio Web
grommunio Web does not automatically show another mailbox in the left folder tree just because folder ACLs exist. For the web client, the functional mailbox was therefore written into each user’s web settings as a shared_stores entry. In grommunio Web 5 this entry belongs under the grommunio namespace; older or migrated profiles may still contain zarafa entries.
USER_A is the user who should see the store. USER_B is the functional mailbox. The shared mailbox address is hex-encoded because grommunio Web stores the shared-store key in that form.
USER_A="alice@example-a.test"USER_B="shared-folders@example-a.test"ID=$(printf '%s' "$USER_B" | xxd -p -c 256)SETTINGS=$(gromox-mbop -u "$USER_A" get-websettings)UPDATED=$(printf '%s' "$SETTINGS" | jq --arg id "$ID" '.settings //= {}| .settings.grommunio //= {}| .settings.grommunio.v1 //= {}| .settings.grommunio.v1.contexts //= {}| .settings.grommunio.v1.contexts.hierarchy //= {}| .settings.grommunio.v1.contexts.hierarchy.shared_stores =(if (.settings.grommunio.v1.contexts.hierarchy.shared_stores | type) == "object"then .settings.grommunio.v1.contexts.hierarchy.shared_storeselse {}end)| .settings.grommunio.v1.contexts.hierarchy.shared_stores[$id] = {"all": {"folder_type": "all","show_subfolders": true}}')printf '%s' "$UPDATED" | gromox-mbop -u "$USER_A" set-websettings
The tested script variant preserves existing settings, initializes missing hierarchy objects and is idempotent. In the lab it was run twice for Alice and Bob without creating duplicates.
Step 7: Test grommunio Web
After the websettings entry, the user must log out and back in. The check must verify not only that the functional mailbox is visible, but also that each user sees only the intended folders.
Alice from example-a.test sees the mounted functional mailbox shared-folders@example-a.test and the permitted Finance folder. Sales is not granted to Alice.
Bob from example-b.test sees the same shared mailbox, but with Bob-specific visibility for Sales and Projects. Finance remains hidden for Bob.
The Project-A ACL is proven through the CLI. In the headless web run, expanding the nested Project-A branch was not counted as a visible web PASS because the tree expansion was not reproducible enough. This detail therefore remains explicitly limited.
Step 8: Set Send-As separately from folder permissions
Folder ACLs and Send-As are separate controls. Alice can read or work in a folder without automatically being allowed to send as shared-folders@example-a.test. Send-As was therefore granted and tested separately via SMTP.
grommunio-admin user sendas shared-folders@example-a.test add alice@example-a.testgrommunio-admin user sendas shared-folders@example-a.test list
The mail-flow test from Alice with From: shared-folders@example-a.test to Bob succeeded. Send-As is therefore proven for the tested internal path.
Step 9: Check the SMTP alias
The alias finance@example-a.test was assigned to the functional mailbox. Mail sent to that alias arrived in the shared mailbox in the lab. The alias itself is therefore verified.
grommunio-admin user modify shared-folders@example-a.test \--alias finance@example-a.testgrommunio-admin user show shared-folders@example-a.test
A server-side rule that automatically moves mail for finance@example-a.test into Finance was not counted as PASS in this run. Alias delivery is confirmed; the inbox rule configuration remains open.
Step 10: Test Thunderbird with a separate lab profile
Thunderbird was tested in an isolated Fedora 44 X11 environment with Xvfb, openbox and scrot. The profile was new and contained only neutral lab accounts.
The version dialog proves the tested Thunderbird version. The screenshots come from the isolated X11 test environment, not from a personal desktop profile.
Account setup was checked with neutral data. Passwords were entered only internally from lab secret files into the running test session and are not visible in screenshots.
Alice was connected via IMAP. The screenshot shows a neutral test message written to the grommunio lab mailbox beforehand.
The functional mailbox shared-folders@example-a.test was added as a separate IMAP account. This is not a delegated Exchange/MAPI shared mailbox model; it is a separate account with its own credentials. Finance, Sales, Projects, Project-A, Project-B and Shared are visible.
The Finance folder contains a neutral test message from the lab. This path is rated Thunderbird IMAP Shared Mailbox PASS WITH CONDITIONS because the mailbox is connected as a separate account.
The nested Project-A folder was also opened in Thunderbird. This makes the functional mailbox folder structure visible and reproducible in the client.
Thunderbird 153.0.2 offers EWS in the manual account setup dialog. This screenshot proves the available native GUI option, but not a completed delegated shared-mailbox setup.
Using the full grommunio EWS endpoint brought Thunderbird to the next step. The same endpoint had already been verified successfully in the direct EWS protocol test.
The GUI test reached the certificate check of the lab endpoint. Because of this lab certificate boundary, Thunderbird EWS remains PASS WITH CONDITIONS for the GUI path. Delegated EWS access to the functional mailbox is not counted as PASS.
Thunderbird IMAP Alice: PASSThunderbird IMAP functional mailbox as separate account: PASS WITH CONDITIONSThunderbird EWS direct protocol test against grommunio: PASSThunderbird EWS GUI normal account: PASS WITH CONDITIONSThunderbird EWS delegated shared mailbox: NOT PASSEDVisible Thunderbird GUI screenshots: PASSOutlook on Windows: NOT TESTED
Public folder vs functional mailbox
The public-folder test showed separate public-folder stores per domain. example-a.test contained Example-A-Public, while example-b.test had its own empty public-folder store. Cross-domain ACLs can be set through the CLI, but that does not replace a full client-side proof for organization-wide public-folder usage.
Public folder:- domain-bound public-folder store- client behavior must be checked per domain- not automatically proven as an organization-wide shared workspace across domainsFunctional mailbox:- normal mailbox with its own folder tree- cross-domain folder ACLs inside the same organization tested- visible in grommunio Web through websettings automount- Send-As and SMTP aliases controlled separately
Troubleshooting
Shared store does not appear in grommunio Web: Check websettings, log the user out and back in, and verify that shared_stores is an object.
gromox-mbop -u alice@example-a.test get-websettings | \jq '.settings.grommunio.v1.contexts.hierarchy.shared_stores'
User cannot see subfolders: Check root foldervisible, all parent folders and the target folder ACL. foldervisible on Projects does not grant content access to Project-A.
User sees too much: Check default rights, anonymous rights, group memberships, recursive grants and accidental StoreOwner or delegate rights.
Send-As fails: Check Send-As separately, select the sender address again in the client and restart the session after permission changes.
Checklist for your own PoC
The server-side PoC is meaningful only when the permitted access paths work and the intentionally denied access paths have been checked as well. This checklist can be used directly as an acceptance record.
- [ ] Both test domains belong to the same grommunio organization.- [ ] A central functional mailbox was created.- [ ] The required folder tree was created.- [ ] User A belongs to domain A.- [ ] User B belongs to domain B.- [ ] Root and parent folders only have the required visibility.- [ ] Target folders have the intended folder ACL.- [ ] User A can open the permitted folder.- [ ] User A cannot open a non-permitted folder.- [ ] User B can open the permitted folder across domains.- [ ] User B cannot open a non-permitted folder.- [ ] The functional mailbox appears in grommunio Web.- [ ] Existing web settings were not overwritten by the automount.- [ ] Send-As was granted and tested separately, if required.- [ ] Client paths that were not fully tested are marked separately.
PASS/FAIL criteria for customer acceptance
PASS in this article means that the specific step was practically executed and the expected result was visible or proven through the CLI. FAIL means that the step was executed but the expected result did not appear, or a user saw more or less than intended. NOT TESTED means that the point was not fully verified in this run and must not be treated as passed.
Result check
The following result check separates confirmed lab results from open client tests. PASS means that the item was practically executed in this test environment.
Area Check ResultShared mailbox Folder tree created PASSACL Cross-domain user permission PASSACL Root/parent foldervisible set PASSACL Non-permitted folders remain inaccessible PASSgrommunio Web Automount visible for Alice and Bob PASSScript Idempotency and empty websettings PASSMail flow Send-As PASSMail flow SMTP alias delivery PASSPublic folder Domain store comparison PASS WITH CONDITIONSThunderbird Separate IMAP account PASS WITH CONDITIONSThunderbird IMAP GUI screenshots PASSThunderbird Direct EWS protocol PASSThunderbird EWS GUI normal account PASS WITH CONDITIONSThunderbird EWS delegated shared mailbox NOT PASSEDOutlook Manual mounting NOT TESTEDInbox rule Move alias mail to Finance automatically NOT TESTED
What will be added later
The architecture, cross-domain folder ACLs, foldervisible, grommunio Web automount, Send-As, alias delivery and Thunderbird as a separate IMAP account are practically tested. The full Outlook test on Windows, the full Thunderbird EWS delegated path and the final inbox-rule test remain open.
Conclusion
For shared folders across multiple domains inside one grommunio organization, a functional mailbox is a clear and testable approach. The key is to avoid blanket Full Access permissions and to treat root and parent visibility, target folder permissions, Send-As and aliases as separate controls.