Passbolt self hosted does not send password recovery email only from administrator

Hello friends!

I use the passbolt in my own structure and I have a very serious problem.

When I try to recover the password of the primary user, who holds all passwords and groups, the recovery email does not arrive in the inbox.

The recovery email usually arrives to the other users of my instance.

Has anyone been through this or have any idea how to solve it?

I have already managed to recover the password of this user several times, but this time the recovery email does not arrive.

I am desperate because this user is the administrator of all passwords and groups in my instance.


Hi @angelogelaskoctbz

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 = '') and type = 'recover' order by created DESC;

Replace with your email of record. Take the first one on the list of results.

Step 2: Build URL with user_id and 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).

And still, tokens are created in the DB, eg:

| id                                   | foobar | 7474b79a-4626-4e39-a828-532c8b9c658f | active | created             | modified            | type     | data |
| 51b5b94a-6317-4f4b-8c2b-bfcbd505cc55 | foobar | 7474b79a-4626-4e39-a828-532c8b9c658f |      1 | 2022-07-01 00:45:54 | 2022-07-01 00:45:54 | recover  | NULL |
| d016b670-bf5f-4ff2-b326-4e3e9b094060 | foobar | 7474b79a-4626-4e39-a828-532c8b9c658f |      1 | 2022-07-01 00:19:37 | 2022-07-01 00:19:37 | recover  | NULL |
| 2743e292-2761-4368-88ab-0b1885af3f58 | foobar | 7474b79a-4626-4e39-a828-532c8b9c658f |      1 | 2022-07-01 00:14:31 | 2022-07-01 00:14:31 | recover  | NULL |
| 77862da0-1359-4a05-8090-dc9262534466 | foobar | 7474b79a-4626-4e39-a828-532c8b9c658f |      1 | 2022-06-30 23:58:44 | 2022-06-30 23:58:44 | recover  | NULL |
| 2b233ecc-c845-446b-af2c-0136f6cd5f18 | foobar | 7474b79a-4626-4e39-a828-532c8b9c658f |      1 | 2022-06-30 12:45:27 | 2022-06-30 12:45:27 | recover  | NULL |
| 32da1dba-46c2-4cbf-b60b-2a57a9728e37 | foobar | 7474b79a-4626-4e39-a828-532c8b9c658f |      1 | 2022-06-30 12:43:47 | 2022-06-30 12:43:47 | recover  | NULL |
| c357572e-c410-4614-88c9-95ccf9c8694b | foobar | 7474b79a-4626-4e39-a828-532c8b9c658f |      1 | 2022-06-30 12:39:35 | 2022-06-30 12:39:35 | recover  | NULL |
| c35e05f7-e4e4-4550-a8fc-582487ed2886 | foobar | 7474b79a-4626-4e39-a828-532c8b9c658f |      1 | 2022-06-30 11:56:04 | 2022-06-30 11:56:04 | recover  | NULL |

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?

Thank you!

Hi @drzraf in the Administration/EmailNotifications section of the app do have you the second option enabled as show here:

Also: Passbolt Help | Why are my emails not being sent?
There are other possible reasons for this, like no CRON running, etc.

  1. I couldn’t access the backend (without launching mysql as suggested previously).
  2. In the administration, the notification are on (btw, I’d expect th admin to always recovery notifications independently of this setting)
    Screenshot from 2022-07-01 22-19-45
  3. I read Passbolt Help | Why are my emails not being sent? but none of the causes mentioned seems adequate.

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:

Jul  1 23:00:01 pubweb60 CRON[334776]: (www-data) CMD ($PASSBOLT_BASE_DIR/bin/cron)

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.

Also, how is your healthcheck report?

     ____                  __          ____  
    / __ \____  _____ ____/ /_  ____  / / /_ 
   / /_/ / __ `/ ___/ ___/ __ \/ __ \/ / __/ 
  / ____/ /_/ (__  |__  ) /_/ / /_/ / / /    
 /_/    \__,_/____/____/_.___/\____/_/\__/   

 Open source password manager for teams
 Healthcheck shell        


 [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


 [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!

I tried enabling debug, but:

ll /var/log/passbolt/
-rw-r--r-- 1 www-data www-data    0  1 juil. 02:51 cli-error.log
-rw-r--r-- 1 www-data www-data    0  1 juil. 02:51 debug.log
-rw-r----- 1 www-data www-data    0  4 juil. 00:00 error.log
-rw-r----- 1 www-data www-data 1989  3 juil. 14:24 error.log.1  ## Just a couple of 404 / MissingRouteException

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 Look for a db table called email_queue.

I only have very old entries in that table and no new tuple appears when I feel the form
Screenshot from 2022-07-04 19-03-19

(That “yyy” value is the email address I’m expecting to receive an email to)

| id | email | sent | locked | send_tries | send_at             | created             |
|  1 | yyy   |    1 |      0 |          0 | 2020-10-24 19:16:53 | 2020-10-24 19:16:53 |
|  2 | xxx   |    1 |      0 |          0 | 2020-10-25 23:42:57 | 2020-10-25 23:42:57 |
|  3 | xxx   |    1 |      0 |          0 | 2020-10-25 23:45:26 | 2020-10-25 23:45:26 |
|  4 | yyy   |    1 |      0 |          0 | 2020-10-27 10:13:40 | 2020-10-27 10:13:40 |

@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?

Yes, I do have tokens generated (see one of my previous messages containing an excerpt of authentication_tokens)


If I understand well, you don’t receive recovery email. Here are some action you can try:

Clear the cache:

sudo -H -u www-data bash -c "/usr/share/php/passbolt/bin/cake cache clear_all"

Run a datacheck (should be all green):

sudo -H -u www-data bash -c "/usr/share/php/passbolt/bin/cake passbolt datacheck --hide-success-details"

Manually trigger the cron command and see if there is any error in the output:

sudo -H -u www-data bash -c "/usr/share/php/passbolt/bin/cake cache clear_all"

Fill the recovery form, then manually trigger the cron job, to check if there is any error:

sudo -H -u www-data bash -c "/usr/share/php/passbolt/bin/cron"

Edit /etc/cron.d/passbolt-ce-server and redirect cron output to a file, to check if there is any error logged:

* * * * * www-data $PASSBOLT_BASE_DIR/bin/cron 2>&1 > /var/log/passbolt/cron.log

Fill the recovery form and wait for the cron to fill /var/log/passbolt/cron.log (can remains empty if no log).

Check these logs for some errors:

  • /var/log/php7.4-fpm.log
  • /var/log/passbolt/error.log
  • /var/log/mail.log
  • your sendmail / postfix / other logs

You can try another SMTP provider.

By the way, for each created email, the email_queue table should contain one additional row. This table don’t grow on each email notification ?


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)
  • No email was sent (no even intended to be sent)


Thank you for the feedback. Does this occurs only for your account or all of your users don’t receive the recovery email ?

It is not normal than your recovery email is not created on email_queue table.

This is weird too.

By reading the healthcheck you posted above, I assume you have installed passbolt from our package on Debian 11.

Do you have only passbolt on your server with the nginx setup ? Can you install the debsums Debian package and post the output of the below command:

sudo apt install debsums
sudo debsums -as --no-prelink --no-locale-purge

It is to check if some files have been altered.

Can you also post your /var/log/passbolt/error.log file ?

Thank you :slight_smile:

Hi again @drzraf,

Can you also check in your email settings if “When users try to recover their account, notify them.” is enabled in your email settings ?


1 Like

That was it:

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)

Thank you very much, @garrett and @_jc


@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.