one of my users wanted to set up a Sieve filter but noticed they could not login to the dashboard. the account does not have 2FA and can successfully auth with Thunderbird and DAV clients using the password. However, they cannot sign in to the web dashboard at /account. I created a test account and am running into the same issue with it, but when I set it as an Administrator, it can login just fine. I’m not trying to login to /admin with non-admins, this is happening on /account. I have my logs set to trace but they still aren’t helpful:
not sure how to get it to reveal more info. Is this a new issue in 0.16.16? Users could login before; I set up my server with 0.16.14 initially.
Stalwart Version
v0.16.x
Installation Method
Binary (Linux)
Database Backend
RocksDB
Blob Storage
RocksDB
Search Engine
Internal
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.
I can’t reproduce this from the server side, and I’ve checked the obvious places: nothing changed between 0.16.14 and 0.16.16 that would gate the account panel on admin rights. The permission enum is unchanged across those tags, roles are only seeded when none exist so an upgrade never rewrites them, and the default User role does carry the sysAccountSettings, sysAccountPassword, sysApiKey and sysAppPassword permissions, which is exactly what that section needs. The /account endpoints themselves require authentication and nothing more.
The piece that did move is the web UI. /admin and /account are two mount paths of the same downloadable bundle, and that bundle updates on its own schedule independently of the server version; 1.0.7 and 1.0.8 landed on 30 and 31 July, right before you upgraded, and 1.0.7 rewrote exactly the code that decides which sections a user may see.
So a few things would help. First, what does the failure actually look like: an error, a blank page, or a bounce back to the login screen? The screenshot didn’t come through. If the panel loads and is simply empty, that’s the section-visibility path rather than authentication, and it’s a different fix. Second, the browser devtools Network tab during a failed sign-in, specifically which request fails and with what status and body. Third, whether it still happens in a private window, since the active account id is now persisted across sessions and a stale one from an admin session in the same profile could select an account the user can’t read. And if you can, the output of stalwart-cli get Account <user> --fields roleIds followed by the role, so I can see the permissions actually granted.
