OIDC users get deactivated upon server start #1996

Open
opened 2026-07-15 19:23:30 +00:00 by kv318 · 9 comments

While setting up a fresh install using exclusively OIDC i noticed that all my users would get deactivated upon restarting the server.

I strongly suspect that this is because the migrations check upon server start deactivates any local accounts which do not have a password set while the OIDC account creation process creates a linked local shadow user that does not have a password.

Quick fix would probably be to check if a value for the given user exists in the openidsubject_localpart table.

While setting up a fresh install using exclusively OIDC i noticed that all my users would get deactivated upon restarting the server. I strongly suspect that this is because the migrations check upon server start deactivates any local accounts which do not have a password set while the OIDC account creation process creates a linked local shadow user that does not have a password. Quick fix would probably be to check if a value for the given user exists in the `openidsubject_localpart` table.
kv318 changed title from OIDC users get deleted upon server start to OIDC users get deactivated upon server start 2026-07-15 19:48:08 +00:00
Owner

Update to version 26.6.2, it includes a fix for this issue.

Update to version 26.6.2, it includes a fix for this issue.
Author

Yes, I read about OIDC related fixes in the release notes.
However I am already using 26.6.2 and still having this issue.

Yes, I read about OIDC related fixes in the release notes. However I am already using 26.6.2 and still having this issue.
Author

Adding relevant log snippets

============
Welcome to Continuwuity 26.6.2 (6ad3e67)!

In order to use your new homeserver, you need to create its first user account.
Open your Matrix client of choice and register an account on my.server using the registration token xyz . Pick your own username and password!
Registration has been temporarily enabled to allow you to create an account. Because registration is not enabled in your configuration, it will be disabled again once your account is created.
Find a list of Matrix clients here: https://matrix.org/ecosystem/clients/

If you're running the server interactively, you may also create the first user through the admin console using the `users create-user` command. Press Ctrl-C to open the console.
If you need assistance setting up your homeserver, make a Matrix account on another homeserver and join our chatroom: https://matrix.to/#/#continuwuity:continuwuity.org
============
WARN call:get_record: tower_sessions_core::session: possibly suspicious activity: record not found in store
WARN call:save: tower_sessions_core::session_store: The default implementation of `SessionStore::create` is being used, which relies on `SessionStore::save`. To properly handle potential ID collisions, it is recommended that stores implement their own version of `SessionStore::create`.
INFO call: conduwuit_service::oidc: Authenticated subject subject="subject_id"
INFO call:complete_session{supplied_user_id=Some("@demouser:my.server") subject="subject_id"}: conduwuit_service::oidc: User @demouser:my.server successfully authorized with OIDC subject="subject_id" user_id="@demouser:my.server"
INFO call:complete_session{supplied_user_id=Some("@demouser:my.server") subject="subject_id"}: conduwuit_service::firstrun: @demouser:my.server has been invited to the admin room as the first user.
INFO call:complete_session{supplied_user_id=Some("@demouser:my.server") subject="subject_id"}: conduwuit_service::users::account: Created new user account for @demouser:my.server
INFO call:complete_session{supplied_user_id=Some("@demouser:my.server") subject="subject_id"}: conduwuit_service::oidc: Shadow user created for @demouser:my.server subject="subject_id" user_id="@demouser:my.server"
INFO conduwuit_service::oidc: Profile import complete
INFO call: conduwuit_service::oauth: Issuing oauth authorization code client_id="client_id" client_name="MyClient" requested_scopes={Device("device"), ClientApi} authorizing_user="@demouser:my.server"
INFO conduwuit_service::oauth: Created new oauth session client_id="client_id" authorizing_user="@demouser:my.server" device_id="device_id" requested_scopes={Device("device"), ClientApi}

and after restart

WARN conduwuit_core::config::check: No support contact information (support_email or support_mxid) is configured in the well_known section. Users in the admin room will be automatically listed as support contacts in the /.well-known/matrix/support endpoint.
INFO conduwuit::server: 26.6.2 (6ad3e67) server_name=my.server database_path="/var/lib/continuwuity" log_levels=info
INFO main:start:open: conduwuit_database::engine::open: Opened database. columns=110 sequence=873 time=637.881455ms
INFO main:start: conduwuit_service::services: Starting services...
INFO main:start: conduwuit_service::migrations: Starting media startup integrity check.
INFO main:start: conduwuit_service::migrations: Finished media startup integrity check in 0.000182372 seconds.
INFO main:start: conduwuit_service::migrations: Running migration 'split_userid_password'
INFO main:start: conduwuit_service::migrations: Marking @demouser:my.server as deactivated
INFO main:start: conduwuit_service::migrations: Split userid_password. remote_users=0

Adding relevant log snippets ``` ============ Welcome to Continuwuity 26.6.2 (6ad3e67)! In order to use your new homeserver, you need to create its first user account. Open your Matrix client of choice and register an account on my.server using the registration token xyz . Pick your own username and password! Registration has been temporarily enabled to allow you to create an account. Because registration is not enabled in your configuration, it will be disabled again once your account is created. Find a list of Matrix clients here: https://matrix.org/ecosystem/clients/ If you're running the server interactively, you may also create the first user through the admin console using the `users create-user` command. Press Ctrl-C to open the console. If you need assistance setting up your homeserver, make a Matrix account on another homeserver and join our chatroom: https://matrix.to/#/#continuwuity:continuwuity.org ============ WARN call:get_record: tower_sessions_core::session: possibly suspicious activity: record not found in store WARN call:save: tower_sessions_core::session_store: The default implementation of `SessionStore::create` is being used, which relies on `SessionStore::save`. To properly handle potential ID collisions, it is recommended that stores implement their own version of `SessionStore::create`. INFO call: conduwuit_service::oidc: Authenticated subject subject="subject_id" INFO call:complete_session{supplied_user_id=Some("@demouser:my.server") subject="subject_id"}: conduwuit_service::oidc: User @demouser:my.server successfully authorized with OIDC subject="subject_id" user_id="@demouser:my.server" INFO call:complete_session{supplied_user_id=Some("@demouser:my.server") subject="subject_id"}: conduwuit_service::firstrun: @demouser:my.server has been invited to the admin room as the first user. INFO call:complete_session{supplied_user_id=Some("@demouser:my.server") subject="subject_id"}: conduwuit_service::users::account: Created new user account for @demouser:my.server INFO call:complete_session{supplied_user_id=Some("@demouser:my.server") subject="subject_id"}: conduwuit_service::oidc: Shadow user created for @demouser:my.server subject="subject_id" user_id="@demouser:my.server" INFO conduwuit_service::oidc: Profile import complete INFO call: conduwuit_service::oauth: Issuing oauth authorization code client_id="client_id" client_name="MyClient" requested_scopes={Device("device"), ClientApi} authorizing_user="@demouser:my.server" INFO conduwuit_service::oauth: Created new oauth session client_id="client_id" authorizing_user="@demouser:my.server" device_id="device_id" requested_scopes={Device("device"), ClientApi} ``` and after restart ``` WARN conduwuit_core::config::check: No support contact information (support_email or support_mxid) is configured in the well_known section. Users in the admin room will be automatically listed as support contacts in the /.well-known/matrix/support endpoint. INFO conduwuit::server: 26.6.2 (6ad3e67) server_name=my.server database_path="/var/lib/continuwuity" log_levels=info INFO main:start:open: conduwuit_database::engine::open: Opened database. columns=110 sequence=873 time=637.881455ms INFO main:start: conduwuit_service::services: Starting services... INFO main:start: conduwuit_service::migrations: Starting media startup integrity check. INFO main:start: conduwuit_service::migrations: Finished media startup integrity check in 0.000182372 seconds. INFO main:start: conduwuit_service::migrations: Running migration 'split_userid_password' INFO main:start: conduwuit_service::migrations: Marking @demouser:my.server as deactivated INFO main:start: conduwuit_service::migrations: Split userid_password. remote_users=0 ```
kv318 reopened this issue 2026-07-16 08:33:55 +00:00
Owner

@kv318 This migration is only supposed to run once, after which a flag is set that stops it from running again. I can't reproduce the behavior of it running on every server startup on 26.6.2 or on main, so I'm baffled by the fact that it seems to never be setting that flag for you.

@kv318 This migration is only supposed to run once, after which [a flag is set](https://forgejo.ellis.link/continuwuation/continuwuity/src/commit/6ad3e679bc51d5382f2d6f2dc44b3fd9616c8bee/src/service/migrations.rs#L885) that stops it from running again. I can't reproduce the behavior of it running on every server startup on 26.6.2 or on main, so I'm baffled by the fact that it seems to never be setting that flag for you.
Owner

If you've been restoring a backup from when you were running 26.6.1, that would be reverting your database to a version without the flag, which makes the migration run again. 26.6.1 doesn't properly set the flag, which is why 26.6.2 was released in the first place.

If you've been restoring a backup from when you were running 26.6.1, that would be reverting your database to a version without the flag, which makes the migration run again. 26.6.1 doesn't properly set the flag, which is why 26.6.2 was released in the first place.
Author

I am runnig a completely fresh install. No pre-existing database.
But this was a very helpful pointer. If i read it correctly, creating a new server calls fresh() instead of migrate() which means the flag is only set after the first restart but not on initial start.
This seems to be confirmed by the problem not appearing when i create a fresh server -> do a restart and only then start creating users.

I am runnig a completely fresh install. No pre-existing database. But this was a very helpful pointer. If i read it correctly, creating a new server calls fresh() instead of migrate() which means the flag is only set after the first restart but not on initial start. This seems to be confirmed by the problem not appearing when i create a fresh server -> do a restart and only then start creating users.
Author

Even when working around this e.g. by running just migrate() after fresh() to prevent this migration from running afterwards i think it is worth considering if treating any password-less users as deactivated is intended behavior of the function.

Even when working around this e.g. by running just migrate() after fresh() to prevent this migration from running afterwards i think it is worth considering if treating any password-less users as deactivated is intended behavior of the function.
Owner

That is the intended behavior of the function, because it's only supposed to run on pre-OIDC databases, and it works perfectly in that case. The only reason it was causing problems is because of a mistake I made in the migration.

That is the intended behavior of the function, because it's only supposed to run on pre-OIDC databases, and it works perfectly in that case. The only reason it was causing problems is because of a mistake I made in the migration.
Author

Okay, yes, then it does indeed make sense to leave it as is and just make sure fresh installations/databases set the the flag.
Until a fix is live, restarting once after initial setup is a decent enough workaround.

Okay, yes, then it does indeed make sense to leave it as is and just make sure fresh installations/databases set the the flag. Until a fix is live, restarting once after initial setup is a decent enough workaround.
Sign in to join this conversation.
No milestone
No project
No assignees
2 participants
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
continuwuation/continuwuity#1996
No description provided.