User password not sent and “Change Login Password” says user does not exist

[csi-williamkanufre]

database = mysql Ver 15.1 Distrib 10.11.14-MariaDB Apache = Server version: Apache/2.4.65 (Debian) Server built: 2025-07-29T20:18:46 OS = Debian 12.12 PHP = PHP 8.2.29

Teampass vesion = 3.1.5.16

I created a user and I don’t know where the password is sent so that the user can log in. Is any notification shown on the screen, or is it sent directly to the registered email?

Another point: when I click on “Change Login Password”, it returns a message saying that the user is not created, but the user is created — otherwise this message wouldn’t appear, correct?

Could you help me with this?

[djosip]

I have a similar setup. Instead of the Apache module, I’m using PHP 8.2 FPM (8.2.29-1). I can confirm this issue occurs in versions 3.1.5.14 and 3.1.5.16 (I skipped 3.1.5.15).

This appears to be the same issue as #4976 (possibly a duplicate).

[nilsteampassnet]

DO you have user with 9999997 inside table users?

[djosip]

DO you have user with 9999997 inside table users?

I have these users in the teampass database:

[root@localhost (teampass)]> select id, login from teampass_users;
+----------+----------+
| id       | login    |
+----------+----------+
|        1 | admin    |
|  9999999 | API      |
| 10000000 | djosip   |
|  9999991 | OTV      |
| 10000001 | testuser |
+----------+----------+

This is completely new setup, without any data added. I just installed it and created two users. Let me know if you need more info.

[csi-williamkanufre]

@djosip @nilsteampassnet It also happens in v3.1.5.13; I installed this version before and the same thing happened.

[daweed38]

Problem still exist in 3.1.5.17

To reproduce :

Fresh install from scratch Pull from github Install process ok Login with Admin ok Create a new user and try to change login password => User not exists

@nilsteampassnet User id 9999997 is not populate by a fresh install

mysql> select id, login from tps_users; +-----------+--------+ | id | login | +-----------+--------+ | 1 | admin | | 9999999 | API | | 10000000 | daweed | | 9999991 | OTV | +-----------+--------+ 4 rows in set (0,00 sec)

mysql>

[csi-williamkanufre]

Same thing happening.

The admin password works normally, but when trying to change the user's password, it gives the same error already reported.

This is happening with a clean installation; I've tested it with versions from 12 to the current one.

[guerricv]

Hello, Have you got something in the devtool and/or in logs ?

[daweed38]

Hello, i don't know how to look / access to devtools, but in MySQL log, tracking request we can see that Teampass request search about an account id 9999997 that is not populate at install. So as it's not an error to not find something in database (juste return a null / empty array result) that why i think we get the "User not exists" error but nothing special appear in logs

[daweed38]

Hello,

After some research I tested the installation of version 3.1.5.x with a dichotomous method, the account "TP" (ID 9999997) is created by the installation procedure up to version 3.1.5.3 but the account is not created in version 3.1.5.4 and higher.

[guerricv]

Hello, i don't know how to look / access to devtools,

in your navigator hit fn+F12, tab console. you can filter output on errors only.

[williamkanufre]

When clicking Launch to reset/generate user keys in TeamPass, it shows 'User does not exist', but the user exists and is listed. The network shows POST /sources/main.queries.php 200 OK with type=user_new_keys_generation and still returns an error. It is necessary to validate in main.queries.php which user identifier is being checked (id/login/email) and the real reason (role/key/status). I suggest a temporary log + standardized JSON return.

Evidence (screenshots attached) UI shows the Launch action and the toast “User not exists” DevTools → Network shows request is made: POST /sources/main.queries.php → 200 OK Payload includes: type = user_new_keys_generation type_category = action_key DevTools → Response shows a long token/string returned, but UI still reports “User not exists”

[guerricv]

I'm trying to reproduce and I confirm user creation is not completing. Have you also an 500 error on the admin.queries.php page ? Something like :

[williamkanufre]

Yeah.

[guerricv]

Root cause found (installer): missing internal “TP” system user (TP_USER_ID = 9999997)

On fresh installs, I hit an admin-side 500 error (TypeError in cryption()) when accessing some admin pages / actions (e.g. “Change Login Password”). The error happens because the code expects the internal TP user to exist in the users table, but SELECT … WHERE id = TP_USER_ID returns no row, so $userInfo is null.

Why the TP user is missing:

• In 3.1.5.17, the installer step that creates the users table no longer includes legacy columns such as groupes_visibles, fonction_id, groupes_interdits, favourites, latest_items.
• However, install/install-steps/run.step6.php still tries to create the TP user using an INSERT that references those removed columns.
• MySQL/MariaDB rejects that INSERT (“unknown column …”), so the TP user never gets created (and the installer doesn’t always surface this clearly).

Quick DB check:

SELECT id, login
FROM teampass_users
WHERE id IN (9999991, 9999997, 9999999);

Expected: OTV (9999991), TP (9999997), API (9999999). In the broken case, TP is missing.

Proposed fix (installer 3.1.5.17):

Edit install/install-steps/run.step6.php and remove the legacy fields from the TP-user INSERT: groupes_visibles, fonction_id, groupes_interdits, favourites, latest_items. Optionally set email and user_ip to none.

Patch snippet (what I changed)

DB::insert($prefix . 'users', [
  'id' => TP_USER_ID,
  'login' => 'TP',
  'pw' => $encryptedUserPassword,
  'derniers' => '',
  'key_tempo' => '',
  'last_pw_change' => '',
  'last_pw' => '',
  'admin' => 1,
  'last_connexion' => '',
  'gestionnaire' => 0,
  'email' => 'none',
  'user_ip' => 'none',
  'personal_folder' => 0,
  'public_key' => $userKeys['public_key'],
  'private_key' => $userKeys['private_key'],
  'is_ready_for_usage' => 1,
  'otp_provided' => 0,
  'created_at' => time(),
]);

How to test quickly:

• Before running a fresh install, replace install/install-steps/run.step6.php in the extracted TeamPass sources with the attached modified file.
• Then perform a fresh install and re-run the DB check above to confirm TP (9999997) is created.
• If TP is present, the admin pages/actions that previously triggered the 500 should no longer fail.

Note: I haven’t been able to fully test this change yet (Christmas Eve on my side), but the root cause is a clear schema mismatch (installer INSERT still referencing removed columns). This patch should restore TP user creation on fresh installs.

I’m attaching the updated run.step6.php file to this comment for easy review/testing.

run.step6.php

Optional hardening: a defensive null-check in sources/admin.queries.php could avoid a hard 500 if TP is missing, but the correct fix is to ensure the installer creates TP successfully.

MERRY CHRISTMAS to all TeamPass users 🎄🎅