I have received error i DB after update from 5.4 to 5.12

Checklist
I have read intro post: https://community.passbolt.com/t/about-the-installation-issues-category/12
I have read the tutorials, help and searched for similar issues
I provide relevant information about my server (component names and versions, etc.)
I provide a copy of my logs and healthcheck
I describe the steps I have taken to trouble shoot the problem
I describe the steps on how to reproduce the issue

I have update from 5.4 to 5.11 and I used to run som chack commands,

su -c “source /etc/environment; bin/cake passbolt datacheck --hide-success-details” -s /bin/bash www-data

this command gives alot of fails

[FAIL] Validation failed for secret ff60be09-8ea6-4cc8-83c5-7f0524c7fa16. {"secret_revision_id":{"_empty":"The secret revision identifier should not be empty."}}
[FAIL] Validation failed for secret ff67365c-4609-4126-ab06-70303a93cf69. {"secret_revision_id":{"_empty":"The secret revision identifier should not be empty."}}
[FAIL] Validation failed for secret ff9b485f-e33b-4fd9-a4ab-b806cecbda6e. {"secret_revision_id":{"_empty":"The secret revision identifier should not be empty."}}
[FAIL] Validation failed for secret ff9ee646-3d76-4658-8dbb-78a6de705d9e. {"secret_revision_id":{"_empty":"The secret revision identifier should not be empty."}}
[FAIL] Validation failed for secret ffae40e6-1de0-4be1-916d-72cf9fe41f07. {"secret_revision_id":{"_empty":"The secret revision identifier should not be empty."}}
[FAIL] Validation failed for secret ffe69931-9ee4-4dd9-b278-8a1ced0b2813. {"secret_revision_id":{"_empty":"The secret revision identifier should not be empty."}}

Is it something new in version 5.12?

Hello,

you might have run across a memory issue when the database migrations were run.
Any information in the error logs?

What is the state of the `phinxlog` table? This command might help diagnose:

SELECT* FROMphinxlog WHERE version >= '20251027060835';

Accordingly we can run some commands to re-run the migrations.

Best!

I have no memory issue on the server when I update the passbolt version.

select * from phinxlog WHERE version >= ‘20251027060835’;
±---------------±-------------------------------------------------±--------------------±--------------------±-----------+
| version | migration_name | start_time | end_time | breakpoint |
±---------------±-------------------------------------------------±--------------------±--------------------±-----------+
| 20251027060835 | V570AddCreatedByAndModifiedByToSecrets | 2025-11-24 14:49:06 | 2025-11-24 14:49:06 | 0 |
| 20251027102352 | V570AddDeletedToSecrets | 2025-11-24 14:49:06 | 2025-11-24 14:49:06 | 0 |
| 20251028213926 | V570CreateSecretRevisions | 2025-11-24 14:49:06 | 2025-11-24 14:49:06 | 0 |
| 20251028223602 | V570AddSecretRevisionIdToSecrets | 2025-11-24 14:49:06 | 2025-11-24 14:49:06 | 0 |
| 20251029053757 | V570PopulateCreatedByAndModifiedByInSecretsTable | 2025-11-24 14:49:06 | 2025-11-24 14:49:15 | 0 |
| 20251105054212 | V570PopulateSecretRevisionsForExistingSecrets | 2025-11-24 14:49:15 | 2025-11-24 14:49:21 | 0 |
| 20251127112629 | V580AddDeletedToRoles | 2026-01-14 14:30:17 | 2026-01-14 14:30:17 | 0 |
| 20251127142638 | V580InsertRbacsControlledActions | 2026-01-14 14:30:17 | 2026-01-14 14:30:17 | 0 |
| 20251128071117 | V580AddByFieldsToRoles | 2026-01-14 14:30:17 | 2026-01-14 14:30:17 | 0 |
| 20251203112523 | V580InsertRbacsForActions | 2026-01-14 14:30:17 | 2026-01-14 14:30:17 | 0 |
| 20251215190450 | V580RemoveUniqueIndexOnRolesName | 2026-01-14 14:30:18 | 2026-01-14 14:30:18 | 0 |
±---------------±-------------------------------------------------±--------------------±--------------------±-----------+

Thank you for that!

It looks like the migrations did run properly. We have two commands that might help fixing the validation fail:

This one is to re-run the V570PopulateCreatedByAndModifiedByInSecretsTable migration:

bin/cake passbolt populate_created_by_and_modified_by_in_secrets

And this one to fix the integrity issue you have on secrets:

bin/cake passbolt populate_secret_revisions_for_existing_secrets

Let me know if this fixed your issue.

Works like charm! Thank you

Can I open this case again because the issue is maybe related:

root@60c4c77940ff:/usr/share/php/passbolt# su -c “./bin/cake passbolt datacheck --hide-success-details” -s /bin/bash www-data

 ____                  __          ____  
/ __ \____  _____ ____/ /_  ____  / / /_ 

/ // / __ `/ / / __ / __ / / _/
/ / // ( | ) // / // / / /
// _,/
/
/./_//__/

Open source password manager for teams

Data check shell
[PASS] Data integrity for AuthenticationTokens.
[PASS] Can validate: 20770/20770
[PASS] Data integrity for Comments.
[PASS] Can validate: 29/29
[PASS] Data integrity for Favorites.
[PASS] Can validate: 45/45
[PASS] Data integrity for Gpgkeys.
[PASS] Can encrypt: 48/48
[PASS] Pass validation service checks: 48/48
[PASS] Entity data and armored key data matches: 48/48
[PASS] Is not expired: 48/48
[PASS] Is armored key format valid: 48/48
[PASS] Data integrity for Groups.
[PASS] Can validate: 36/36
[PASS] Data integrity for Profiles.
[PASS] Can validate: 111/111
[FAIL] Data integrity for Resources.
[FAIL] Can validate: 5955/5958
[FAIL] Validation failed for resource 8f4ca484-ecd7-4f7f-931a-2f01ccdc7418. {“name”:{“noInvisibleCharacters”:“The string should not contain invisible characters.”},“permissions”:{“_required”:“The permissions are required.”},“secrets”:{“_required”:“The owner secret is required.”}}
[FAIL] Validation failed for resource cf8e49fa-301e-4359-8baf-0d19afda9a75. {“name”:{“noInvisibleCharacters”:“The string should not contain invisible characters.”},“permissions”:{“_required”:“The permissions are required.”},“secrets”:{“_required”:“The owner secret is required.”}}
[FAIL] Validation failed for resource e1686377-39c0-4f0a-852a-b11c8cd0670f. {“name”:{“noInvisibleCharacters”:“The string should not contain invisible characters.”},“permissions”:{“_required”:“The permissions are required.”},“secrets”:{“_required”:“The owner secret is required.”}}
[PASS] Is metadata key exist and active: 0/0
[PASS] Data integrity for Secrets.
[PASS] Can validate: 36760/36760
[PASS] Data integrity for Users.
[PASS] Can validate: 111/111
[PASS] Data integrity for MetadataKeys.
[PASS] Check metadata private keys present: 0/0
after updating from: 5.14.3 to 5.15.0 . I have tried the commando above but not resolve the issue.

to be clear the issue is here:
[FAIL] Data integrity for Resources.
[FAIL] Can validate: 5955/5958
[FAIL] Validation failed for resource 8f4ca484-ecd7-4f7f-931a-2f01ccdc7418. {“name”:{“noInvisibleCharacters”:“The string should not contain invisible characters.”},“permissions”:{“_required”:“The permissions are required.”},“secrets”:{“_required”:“The owner secret is required.”}}
[FAIL] Validation failed for resource cf8e49fa-301e-4359-8baf-0d19afda9a75. {“name”:{“noInvisibleCharacters”:“The string should not contain invisible characters.”},“permissions”:{“_required”:“The permissions are required.”},“secrets”:{“_required”:“The owner secret is required.”}}
[FAIL] Validation failed for resource e1686377-39c0-4f0a-852a-b11c8cd0670f. {“name”:{“noInvisibleCharacters”:“The string should not contain invisible characters.”},“permissions”:{“_required”:“The permissions are required.”},“secrets”:{“_required”:“The owner secret is required.”}}
the appliaction is running but the issue are there? How can I resolve it and how to avoid it when using passbolt?

Hi Ahmad,

The datacheck output identifies three resources that fail validation, but the error messages alone do not confirm the root cause.

The affected resource IDs are:

8f4ca484-ecd7-4f7f-931a-2f01ccdc7418
cf8e49fa-301e-4359-8baf-0d19afda9a75
e1686377-39c0-4f0a-852a-b11c8cd0670f

Before taking any action, I need to identify these resources and understand their current state.

For this, you will need access to your Passbolt database.

First, connect to your MariaDB database:

mariadb -uUSERNAME -pPASSWORD passbolt

Replace USERNAME and PASSWORD with your database credentials. Replace passbolt with your actual Passbolt database name if it is different.

Once connected to MariaDB, run the following query:

SELECT id, name, created, modified, created_by, modified_by
FROM resources
WHERE id IN (
'8f4ca484-ecd7-4f7f-931a-2f01ccdc7418',
'cf8e49fa-301e-4359-8baf-0d19afda9a75',
'e1686377-39c0-4f0a-852a-b11c8cd0670f'
);

Please share the result (make sure to hide any sensitive information).

Also, could you confirm the following:

  • Are these resources visible in the Passbolt UI?
  • Can users open and use them normally?
  • Did the issue appear only after upgrading to version 5.15.0?

The validation messages mention possible invisible characters, missing permissions, and missing secrets. However, we first need to determine whether these are isolated issues with these specific resources or if there is a larger problem.

Once I know the state of these resources, I will be able todetermine the appropriate next steps.

Let me know how it goes.

Cheers.

Thanks I found the issue, there is TAB in Username. but it happend when I moved and restored the database.

Hi Ahmad!

Good catch on the TAB character, that could explain the “noInvisibleCharacters” validation error.
The simplest way to fix it is directly from the passbolt UI:

  • Log in as a user who owns (or can edit) the 3 affected resources:
    • 8f4ca484-ecd7-4f7f-931a-2f01ccdc7418
    • cf8e49fa-301e-4359-8baf-0d19afda9a75
    • e1686377-39c0-4f0a-852a-b11c8cd0670f
  • Open each one and edit it. Delete the tab from the name and username fields, retype the value if needed, and save.
  • Then rerun the datacheck:
    • su -c “./bin/cake passbolt datacheck --hide-success-details” -s /bin/bash www-data

Since the tab appeared after the database restore, could you tell us how you did it?

Also, did you see any errors or warnings during the restore, and did the row counts match between the old and new database? Could you please share the output of the datacheck after updating the ressources to see if it solve the issues.

Thanks!

all good after delete the tab in the name and password.
update: the TAB is created after the update not restoring the database. because it happend even in Production.