Without knowing the issue of why your email is not being either delivered or received, you could attempt to manually begin the recovery through these two steps:
Step 1: Get the recovery token from the database with this SQL command: select user_id, token from authentication_tokens where user_id = (select id from users where username = 'your@email.com') and type = 'recover' order by created DESC;
Replace your@email.com with your email of record. Take the first one on the list of results.
Step 2: Build URL with user_id and token: https://<your_domain>/setup/recover/<user_id>/<token>
I’m experiencing the very same problem using passbolt-ce-server 3.6.0 (natively on Debian)
cake passbolt send_test_email successfully send emails (using localhost:25 which point to msmtpd), but recovery emails are not sent by Passbolt (no trace of even an attempt of sending them).
I tried to enable debug (/etc/passbolt/passbolt.php, "debug" => true, ...) but no /var/log/passbolt/debug.log even though owner/perms are correct and the error.log works, but does not provide any information)
How could I further debug the recovery email process and its state?
How/where could I check the email where actually enqueued so that if it’s a cron problem, I should be able to find traces of pending/unsent emails somewhere in the DB or the FS ?
@drzraf Regarding CRON jobs on the current package install with debian, #3 in the email troubleshooting link above explains you should be able to find a job configured at /etc/cron.d/passbolt-ce-server which runs every minute and on my Ubuntu install appears in syslog and looks like:
You mentioned you are sending to localhost at port 25…so I would guess (without knowing more about your email configuration) that your messages might be stored in the local mail queue.
Your /var/log/mail.log would have messages regarding outgoing emails and if there are none there, you might want to look for a file in /var/mail/ which would contain messages for a server user like www-data that were received locally.
____ __ ____
/ __ \____ _____ ____/ /_ ____ / / /_
/ /_/ / __ `/ ___/ ___/ __ \/ __ \/ / __/
/ ____/ /_/ (__ |__ ) /_/ / /_/ / / /
/_/ \__,_/____/____/_.___/\____/_/\__/
Open source password manager for teams
-------------------------------------------------------------------------------
Healthcheck shell
-------------------------------------------------------------------------------
Environment
[PASS] PHP version 7.4.28.
[PASS] PCRE compiled with unicode support.
[PASS] The temporary directory and its content are writable and not executable.
[PASS] The logs directory and its content are writable.
[PASS] GD or Imagick extension is installed.
[PASS] Intl extension is installed.
[PASS] Mbstring extension is installed.
Config files
[PASS] The application config file is present
[PASS] The passbolt config file is present
Core config
[FAIL] Debug mode is on.
[HELP] Set debug = false; in config/passbolt.php
[PASS] Cache is working.
[PASS] Unique value set for security.salt
[PASS] Full base url is set to https://xxxx
[PASS] App.fullBaseUrl validation OK.
[PASS] /healthcheck/status is reachable.
SSL Certificate
[PASS] SSL peer certificate validates
[PASS] Hostname is matching in SSL certificate.
[PASS] Not using a self-signed certificate
Database
[PASS] The application is able to connect to the database
[PASS] 26 tables found
[PASS] Some default content is present
[PASS] The database schema up to date.
GPG Configuration
[PASS] PHP GPG Module is installed and loaded.
[PASS] The environment variable GNUPGHOME is set to /var/lib/passbolt/.gnupg.
[PASS] The directory /var/lib/passbolt/.gnupg containing the keyring is writable by the webserver user.
[PASS] The server OpenPGP key is not the default one
[PASS] The public key file is defined in config/passbolt.php and readable.
[PASS] The private key file is defined in config/passbolt.php and readable.
[PASS] The server key fingerprint matches the one defined in config/passbolt.php.
[PASS] The server public key defined in the config/passbolt.php (or environment variables) is in the keyring.
[PASS] There is a valid email id defined for the server key.
[PASS] The public key can be used to encrypt a message.
[PASS] The private key can be used to sign a message.
[PASS] The public and private keys can be used to encrypt and sign a message.
[PASS] The private key can be used to decrypt a message.
[PASS] The private key can be used to decrypt and verify a message.
[PASS] The public key can be used to verify a signature.
[PASS] The server public key format is Gopengpg compatible.
[PASS] The server private key format is Gopengpg compatible.
Application configuration
[PASS] Using latest passbolt version (3.6.0).
[PASS] Passbolt is configured to force SSL use.
[PASS] App.fullBaseUrl is set to HTTPS.
[PASS] Selenium API endpoints are disabled.
[PASS] Search engine robots are told not to index content.
[PASS] Registration is closed, only administrators can add users.
[PASS] Serving the compiled version of the javascript app
[PASS] All email notifications will be sent.
JWT Authentication
[PASS] The JWT Authentication plugin is enabled
[PASS] The /etc/passbolt/jwt/ directory is not writable.
[PASS] A valid JWT key pair was found
[FAIL] 1 error(s) found. Hang in there!
Regarding cron, it runs, indeed, every minute and it’s unlikely to be an issue with sendmail because I don’t see even an attempt to run anything mail-related. That’s why I want to know whether passbolt actually even tried.
If email are sent by bin/cron, it means that passbolt creates and store sent intents somewhere inside the DB or the filesystem (a queue). Could you help me find them? My guess is that the bug lays inside PHP which does not actually call sendmail() even though it shows “Check your inbox”.
@drzraf Those are pretty old. The thread you originally posted on (link found under your first post above) has instructions on how to manually get the keys you need from the db in order to recover your user, but if the email is not being queued…are you seeing recovery keys for your user at all?
Did all the suggested commands : Alright (except the cache clear which complain about The "_cake_routes_" cache configuration does not exist.).
Then I did the following:
I requested a recovery email (Switch to another account > users/recover > fill the email / accept the terms > [above screenshot that an email was sent).
Cron ran, cron.log was created as expected but is empty
A new tuple was inserted inside authentication_tokens (type=recover)
email_queue is still as posted above (no change) and the AUTO_INCREMENT=5 (showing that no tuple was created and remove afterwards)
but note that I attached a screenshot in that comment and this setting didn’t appear back then.
My guess that after the version upgrade, the cache was not cleared (or not enough) so the “old” admin’ screen was shown to me and IIUC, the default is to not notify.
The biggest problem to this is that disabled notifications implies keeps even the administrator from receiving them and since he is locked out, he can’t even connect in order to change this very setting…
I suggest to improve cache-clearing after upgrade (on Debian) and/or ensure notification are on by default (or always on for the administrator)
@drzraf I’m glad to hear that it’s working again!
You mentioned this a couple of times so I thought would respond as having an admin locked out is clearly a bad scenario. Documentation states that all default are are set to true. Passbolt Help | How to configure email notification settings for your organization. In the /etc/passbolt/default.php file you will find defaults and they are set to true.
For future reference and anyone else who might run into this scenario, the assumption is the admin has access to the db. In addition to overriding any defaults we have statically overwritten in the config files, we can select * from organization_settings to see what the status is of anything we can’t reach in the UI.
I also have the same issue. But my settings at the administrator look like the screenshot I attached. For some reason the test mail is sent succesfuly, but the recovery mail isn’t. I tried every step in this post,but still no mail. Could it be that there is an error in the first entry of the queue table that silently kills the cron or something?
