Thank you for your patience and help in debugging this. The most likely cause for this is an OAuth2 credential that got corrupted during a token refresh. We have a fix for that in here. This caused the above mentioned error when trying to list credentials. The error shown in this case is wrong. The credential can be decrypted but it’s mangled so it can’t be parsed. We have a fix for that here.
I can confirm a workaround in the meantime :
- First, run the following script in your db to get a list of all credentials ordered by
updatedAt
:
SELECT p."name" AS "projectName", c."name" AS "credentialName", c."type", c."createdAt", c."updatedAt", "isManaged"
FROM credentials_entity AS c
JOIN shared_credentials AS sc ON c.id = sc."credentialsId"
JOIN project AS p ON p.id = sc."projectId"
ORDER BY c."updatedAt" DESC
;
- Take the oldest one and try this by using the CLI :
n8n export:credentials --id=<id> --decrypted
- Delete everyone that result in the following errors :
2025-01-28T08:06:56.562Z | error | Error exporting credentials. See log messages for details. {"file":"credentials.js","function":"catch"}
2025-01-28T08:06:56.563Z | error | Credentials could not be decrypted. The likely reason is that a different "encryptionKey" was used to encrypt the data. {"file":"credentials.js","function":"catch"}
- You should now be able to use the following command and hence your admin account should no longer have any problem :
n8n export:credentials --decrypted --all
Thanks n8n team for the fast reponse to this issue!
Thanks for the update on this - will there be a version update released to fix this bug?
Yup, tested it aswell, same output as:
2025-01-28T08:06:56.562Z | error | Error exporting credentials. See log messages for details. {“file”:“credentials.js”,“function”:“catch”}
2025-01-28T08:06:56.563Z | error | Credentials could not be decrypted. The likely reason is that a different “encryptionKey” was used to encrypt the data. {“file”:“credentials.js”,“function”:“catch”}
Luckily it was just a few creds.
@Alex_Stewart These fixes will go out in the next release tomorrow, and we’ll probably backport them to 1.76.x
as well.
Thank you and for the explanation, too!
New version [email protected]
got released which includes the GitHub PR 12880.
Just updated to 1.77.3 from 1.74.x and got the same issue now.
Very old setup, so probably those Old credentials that are the issue.
Updated cloud instance to 1.77.3
Workflows seem to be running fine, however cant access the credentials tab.
Please help on how to fix this.
Having this exact same error, but in only one environment.
One environment I’m not able to open the credentials page and it’s showing the credentials error notification, in another environment with the same version not having the error.
Migrated from 1.71.3 to 1.77.3.
Edit: following the workaround from RedeyeFR
I changed the query to include the id of the credential:
SELECT c."id" as id, p."name" AS "projectName", c."name" AS "credentialName", c."type", c."createdAt", c."updatedAt", "isManaged"
FROM credentials_entity AS c
JOIN shared_credentials AS sc ON c.id = sc."credentialsId"
JOIN project AS p ON p.id = sc."projectId"
ORDER BY c."updatedAt" DESC
;
With that id list, I ran
n8n export:credentials --id=<id> --decrypted --separate --output=credentials
The CLI breaks when finding a bad credential, so we can’t use the --all argument, but running one on one and outputting the results to a folder, now I have a list of JSON files with the credentials that aren’t broken.
So that filters out the list of credential IDs that need to be deleted.
Edit 2: after deleting all credentials that failed to decrypt, the credentials page started loading normally.
I have had this issue on my own instance and of a client. Both very old instances.
Removing all credentials with a numeric Id fixes it.
Hi guys,
We introduced a fix in 1.79.0
that now allows you to load the UI and identify the broken credentials (labelled as Needs first setup
)
Do let us know if this works for you
Sadly not able to actually test this, as I had to fix it by removing credentials via the database.
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.