Hi, I'm new to osTicket.  I like everything that it has to offer.  However, I cannot seem to get email fetching to work.  We are using Office 365.  Yes, IMAP is enabled on the mailbox.  When I enter my settings for the mailbox, it does not give me any errors.  Whereas if I were to purposefully enter erroneous settings, it would give me an error when I try to save them.  So I know that it can communicate with the mailbox. Here is my server information:osTicket Versionv1.10.1 (9ae093d) —  Up to dateWeb Server SoftwareApache/2.4.27 (Ubuntu)MySQL Version5.7.21PHP Version7.1.11-0ubuntu0.17.10.1Here are my email fetching settings on the mailbox:Status:  EnableHostname:  outlook.office365.comPort Number:  993Mail Box Protocol:  IMAP + SSLFetch Frequency:  1 minutesEmails Per Fetch:  30Fetched Emails:  Delete emailsFetching is enabled, but nothing seems to be happening.  New tickets aren't created, and nothing is being deleted from the mailbox.Any help you can offer would be greatly appreciated.

PHP versions over 7.0 are not yet support, recommended version is 5.6Some people are running it with 7.0 with no issues but a handful of others have reported wonkiness.Try downgrading your PHP and see if that resolves your issue.

Is there an easy way to downgrade to 5.6?

We aren't running Apache on our server, we use IIS under Windows, so I can't really give you any instructions. I think its possible to run multiple version of PHP on the same server (windows servers anyway).

So I rebuilt my server, this time using PHP 5.6.  Still not working.

You must be doing something wrong. We use O365 and collect email from it for six (6) different accounts in our main production site. So it works just fine.Here are some things that you should check:What error are you getting?Are you running cron.php on a schedule?Can the web server talk to the mail server?Does the User account have IMAP or POP (whichever one you are using) enabled? (in O365)Are you running any products like SELinux, or mod_apache, or other firewall?  If so have you made connection rules to allo the connections?Are you using dedicated accounts? Have you tried adding ssl:// to the hostname?

Hi ntozier, Thank you for jumping into this discussion.  I assumed that I'm doing something wrong, and that the fix is probably an easy one.  Here are answers to your questions in the order in which they are asked:Not getting any errors.  The system can send emails just fine, so I don't think connection is a problem.Not using cron.php on a schedule.  The little question mark next to the "Fetch on auto-cron" setting suggests that emails won't be fetched unless someone is logged into the SCP.  Since we would need it fetching regardless of having some logged in, I left this option unchecked.Yes.  As stated before, emails are sent just fine.  It's just not fetching.As stated in my original post, IMAP is enabled on the mailbox.Not to my knowledge.  Connection is obviously happening.  As stated in my first post, "When I enter my settings for the mailbox, it does not give me any errors.  Whereas if I were to purposefully enter erroneous settings, it would give me an error when I try to save them.  So I know that it can communicate with the mailbox."  So it obviously tries the settings that I put in when I click "Save Changes."  With the settings I'm using currently, it's not giving me any errors, which indicates to me that it is communicating just fine.Yes.When I enter "ssl://" into the Hostname setting, upon clicking "Save Changes" I get an error, and it does not allow me to save the changes.  So that leads me to think that it should be omitted.

It sounds like you are going to need to setup cron.php on a schedule.  "Fetch on auto-cron" is used if your not or cannot run cron.php on a schedule.

Ok, based on what I found at http://osticket.com/wiki/POP3/IMAP_Setting_Guide, I edited /etc/crontab and added the following line:*/1 * * * * root /usr/bin/php /var/www/html/api/cron.phpIt still doesn't seem to be working.

the default in Ubuntu Apache user is www-data, not root.I don't run Ubuntu (I run Debian though) so if you check your apache2.conf you should have something like User $APACHE_RUN_USERif it's followed by the system user that Apache runs as then that's the username you use.  If not then it might be set in: /etc/apache2/envvars and you would use the variable in apache2.conf to locate it in that file.example:export APACHE_RUN_USER=www-data

I actually tried to manually run the following:sudo php /var/www/html/api/cron.phpI got this:PHP Warning:  Declaration of AssignmentForm:($options) should be compatible with Form:($staff = true, $title = false, $options = Array) in /var/www/html/include/class.forms.php on line 4367PHP Warning:  Declaration of TransferForm:($options) should be compatible with Form:($staff = true, $title = false, $options = Array) in /var/www/html/include/class.forms.php on line 4487PHP Fatal error:  Uncaught Error: Call to undefined function mysqli_init() in /var/www/html/include/mysqli.phpStack trace:#0 /var/www/html/bootstrap.php(182): db_connect('localhost', 'root', 'Zoolander1!', Array)#1 /var/www/html/main.inc.php(28): Bootstrap:()#2 /var/www/html/api/api.inc.php(23): require_once('/var/www/html/m...')#3 /var/www/html/api/cron.php(17): require('/var/www/html/a...')#4 {main}  thrown in /var/www/html/include/mysqli.php on line 28So it seems to me that I have problems other than those of crontab.

@[deleted]That's a PHP 7 issue with a fix here: https://github.com/osTicket/osTicket/pull/3349So it seems like you didn't downgrade to PHP 5.6 successfully. Either implement the fix or successfully downgrade to PHP 5.6.Cheers.

Thats what it looked like to me too... but you said you downgraded...

No, I didn't just downgrade.  I rebuilt the server with PHP 5.6.  Afterwards, when I installed osTicket, I made sure it had green checks next to everything before I continued.

So, I once again completely rebuilt my web server.  Not upgraded, not downgraded, but blown away the old server and rebuilt, with PHP 5.6.  I ran "sudo php /var/www//html/api/cron.php" again, and got the exact same errors as shown above.

I should also mention that upon installation of osTicket, all the punch list items had green checks.

I've run a bunch of different versions of PHP and OSes and webservers, I've done a ton of installations and I have not once ever gotten this error, so I can only conclude that you are in fact using PHP 7.1+ and not 5.6 like you are claiming to be running.You should try applying the fix that @[deleted] linked you and see if that helps.

DUDE! THIS IS A NEW SERER BUILD!  AS STATED TWICE BEFORE, I ONLY INSTALLED PHP 5.6!  I NEVER EVEN INSTALLED 7 ON THIS SERVER BUILD! That said, here is a copy and paste from the top of my information page, which proves I'm on 5.6:Server InformationosTicket Versionv1.10.1 (9ae093d) —  Up to dateWeb Server SoftwareApache/2.4.27 (Ubuntu)MySQL Version5.7.21PHP Version5.6.34-1+ubuntu17.10.1+deb.sury.org+1

Maybe there is something wrong with that PHP repo on Ubuntu? I'm using same version, same php version, on CentOS server, and running cron manually via command line and not getting this error at all. This error is only seen when using PHP version 7.x+. There is a fix here so try making the changes and see if it starts working: https://github.com/osTicket/osTicket/pull/3349Cheers.

OK, I figured out what was going on... sort of.  I'll give a more detailed update in a moment.

If I ran "php -v," it told me that I was running some PHP 7.2.3 version, even though my SCP Dashboard/Information page showed I was using 5.6.34.  (?)  I never installed anything that had to do with PHP 7 at all.  So I ran the following command:sudo update-alternatives --set php /usr/bin/php5.6Then I ran "php -v" again, and it showed the right version.  Now when I run cron.php manually, it fetches e-mails.  Now I'm just not sure why I had that weird version of PHP to begin with, but the bottom line is that it's working now.Thanks to everyone that has commented.

Write a Reply...