Inbound Email cannot function without the IMAP c-client libraries enabled/compiled with the PHP module

I just installed my first SuiteCRM (migrating to 7.11.9 from Insightly) which now seems to work on a Raspberry Pi 3B (so debian/linux), php 7.3 and apache2. I have contacts, users, etc. all working (thank you for prior help with permissions). And I successfully set up my SMTP test email for the system.

However, can’t seem to set up the inbound email (which is preventing me from using SuiteCRM to keep track of who I email). I get the error "Inbound Email cannot function without the IMAP c-client libraries enabled/compiled with the PHP module’.

I generally like to suffer through trying to get things to work before I ask for help (it’s been a long 8 days on this project), and I’ve checked to be sure my php.ini files (multiple) all have extension=imap and extension=php_imap (with DLL for php7.1 and without for 7.3) enabled. And when I run phpinfo() it shows imap is enabled with c-Client (version 2007f), SSL.

So now I’m running out of ideas to try. Any suggestions?

(I probably should mention that I’m a permissions idiot so if this is a possibility, this probably should be near the top of the list.)


Check out this post, may be it help you

Thank you for your help and that post. I did see it and tried several things from it before posting my question, but obviously not enough of them… (as I’ll demonstrate below)

I made sure all my php.ini files were imap enabled (both in 7.3 and 7.1 to be safe, and in apache, cli and fpm). And when I type " php -m " it says imap is enabled. And when I rin phpinfo() it says imap is enabled and gives me a c-Class version running (2007f) and that SSL is running.

When I run " sudo service php7.3-fpm status " I see that it is active, although running " sudo service php7.1-fpm status " can’t find service.

But now when I look at it using " sudo php -i | grep php.ini " it says we’re using php7.3 (as I thought) but unable to load “php_imap” as I added to each php.ini (although imap is enabled and working from above).

And I also get “PHP Warning: Module ‘intl’ already loaded in Unknown on line 0” which says I’m loading it twice (which may not be an issue, or is definitely an issue?) . On the plus side it confirms that we are using php 7.3 and is coming from the proper cli/php.ini .Should I turn " extension=imap " off in apache/php.ini and/or fpm/php.ini?

So the question is “are either of these the problem keeping incoming emails from working? – is php_imap needed separately from imap?” And if so, “how do I fix it”? I can’t seem to find a way to install php_imap for php7.3.


Does anyone have an idea if extension=php_imap is needed separately from extension=imap if imap is enabled?

Or any thoughts how I can get this working?

This is what I use to install on PHP 7.3

apt install zip unzip iotop htop php-mbstring php7.3-mbstring php-gettext php-xml php7.3-zip php7.3-imap php7.3-gd php7.3-curl php7.3-intl php7.3-mysql php-gd phpmyadmin php-xdebug

Thank you.

Ran this and my system had all but these four: iotop php-gettext php7.3-intl php-xdebug. I then restarted apache, and ran phpinfo() to show imap (below):


IMAP c-Client Version => 2007f
SSL Support => enabled
Kerberos Support => enabled

Directive => Local Value => Master Value
imap.enable_insecure_rsh => Off => Off

But unfortunately still see “Inbound Email cannot function without the IMAP c-client libraries enabled/compiled with the PHP module. Please contact your administrator to resolve this issue.”

Is there something I should be doing? Or looking for?

(some of those are not really necessary - iotop is just a utility to check disk usage and Xdebug is for development - you should even remove it in prodution machines)

Next step is to enable those extensions in php.ini and restarting your web server.

Make sure you’re editing the correct php.ini (lots of times this is the problem), check its exact path and the effective values you have in Admin / Diagnostics / phpinfo.

Yo have to do this TWICE, once for Web server PHP and once for CLI.

The CLI is command-line PHP, which is what the scheduler jobs use, including some email functions.

To know the path use

php -i | grep php.ini

To check other values grep it differently:

php -i | grep -i imap

Ok, thanks for the help here. Definitely would be lost without it. I’ve documented it as best I can here in case this helps someone else.

So successfully installed/re-installed the packages as above, into the cli/php.ini . fpm/php.ini and apache/php.ini (just to be safe) as I said above. And I had restarted Apache, but restarted it myself.

But when I tried " php -i | grep php.ini " I received a laundry list of errors from these new extensions which essentially said “HP Warning: PHP Startup: Unable to load dynamic library…” for most of the newly added extensions. So that means I have a path issue (or possibly a permissions issue).

And then when I created a “phpinfo()” page it now says I’m running php7.1, not 7.3 (which wasn’t true at the beginning of this process, so I must have screwed something up/back to php7.1 in my desperate flailings). But php -v and php -i show php7.3. So I fixed this with a2dismod and a2enmod and now phpinfo() and
php -i both show 7.3 properly.

So, without fixing the errors “HP Warning: PHP Startup: Unable to load dynamic library…” for most of the new extensions, the SuiteCRM error “Inbound Email cannot function without the IMAP c-client libraries enabled/compiled with the PHP module” has now disappeared.

So is all good? Let’s check first. I successfully set up a personal email and see my emails in the inbox (and it let me select the inbox, sent and trash folders). So that’s good.

And I successfully sent an outgoing (from SuiteCRM) test email from this account and received it no problems (and said it was from the correct account). So that’s good.

But my first “user generated” email sent (outgoing from SuiteCRM user login) as a test failed, and said “Error Sending Email. Please contact your administrator for assistance.” and the SuiteCRM log said " [FATAL] SugarPHPMailer encountered an error: SMTP Error: Could not authenticate. " which is strange since how did the user test email correctly get sent from the user account if the user can’t authenticate?

It looks like this is a more common issue:

So to summarize: thank you for your help: I am now able to configure incoming emails, although I couldn’t say specifically which of these changes fixed the issue. And now I have more work to do on getting user emails out. But I’ll struggle with this for a few more days and see if I can get it working.

Thank you.