Dear all,

I'm posting since I've got a new setup witch is giving me hard times when opening a Ticket upon receiving an emai.

here is the setup:

Osticket Setup

OS is Oracle Linux 8.8 on Azure VM (b2S)

Now the SMTP test is functioning correctly with oAuth2 Microsoft (we have O365 mailboxes), and on O365 everything has been setup including endpoint callbacks and tokens.

For some reason, upon receiving an email to the configured mailbox nothing happens. No ticket is created.

Here is the email setup:

Here is my crontab configuration

To allow better troubleshooting, SELinux is set to disable.

Any help with this? where can I start to troubleshoot correctly?
Thanks for your help

      Miuruda-san

      Run the cron command manually without the > /dev/null … part and see if there are any errors. You can set your Default Log Level to DEBUG and if cron runs successfully you’ll see a System Log entry for Cron Job. Also check your System Logs for any Mail Fetcher errors. Also, make sure the php in your cron command points to the appropriate version of PHP (eg. run php --version). Also, make sure when you click Config (next to Authentication under the Remote Mailbox tab) that you see a new tab called Token and that the Resource Owner is the correct user (ie. the system email).

      Cheers.

          a month later

          KevinTheJedi
          Thank you for your reply. So after some troubleshoot I got mail fetching to work but only when users are logged in.

          Here is a screen of my /etc/crontab file

          I get these logs and no fetching:

          Dec 10 20:40:01 osticket CROND[7652]: (nobody) CMD (/usr/bin/php /var/www/osTicket/upload/include/cli/modules/cron.php)
          Dec 10 20:40:01 osticket CROND[7641]: (nobody) CMDOUT (PHP Fatal error: Uncaught Error: Class "Module" not found in /var/www/osTicket/upload/include/cli/modules/cron.php:3)
          Dec 10 20:40:01 osticket CROND[7641]: (nobody) CMDOUT (Stack trace🙂
          Dec 10 20:40:01 osticket CROND[7641]: (nobody) CMDOUT (#0 {main})
          Dec 10 20:40:01 osticket CROND[7641]: (nobody) CMDOUT ( thrown in /var/www/osTicket/upload/include/cli/modules/cron.php on line 3)
          Dec 10 20:42:01 osticket CROND[7690]: (nobody) CMD (/usr/bin/php /var/www/osTicket/upload/include/cli/modules/cron.php)
          Dec 10 20:42:01 osticket CROND[7679]: (nobody) CMDOUT (PHP Fatal error: Uncaught Error: Class "Module" not found in /var/www/osTicket/upload/include/cli/modules/cron.php:3)
          Dec 10 20:42:01 osticket CROND[7679]: (nobody) CMDOUT (Stack trace🙂
          Dec 10 20:42:01 osticket CROND[7679]: (nobody) CMDOUT (#0 {main})
          Dec 10 20:42:01 osticket CROND[7679]: (nobody) CMDOUT ( thrown in /var/www/osTicket/upload/include/cli/modules/cron.php on line 3)

          If I launch the same command manually I get the same error:

          [root@osticket etc]# sudo -u apache /usr/bin/php /var/www/osTicket/upload/include/cli/modules/cron.php
          PHP Fatal error: Uncaught Error: Class "Module" not found in /var/www/osTicket/upload/include/cli/modules/cron.php:3
          Stack trace:
          #0 {main}
          thrown in /var/www/osTicket/upload/include/cli/modules/cron.php on line 3
          [root@osticket etc]#

          Any suggestions on this please?

              Miuruda-san

              What version of PHP is /usr/bin/php in your environment? It could be that the path you are using refers to an older version of PHP and not 8.2 like osTicket is expecting.

              Cheers.

                  Miuruda-san

                  Don’t trust Crap-GPT yet for code related stuff. It’s more than likely a PHP version difference. Run /usr/bin/php --version and see what you get.

                  Cheers.

                      KevinTheJedi

                      I already answered this in the thread above

                      [root@osticket modules]# /usr/bin/php --version
                      PHP 8.2.12 (cli) (built: Oct 24 2023 19:22:16) (NTS gcc x86_64)
                      Copyright (c) The PHP Group
                      Zend Engine v4.2.12, Copyright (c) Zend Technologies
                      with Zend OPcache v8.2.12, Copyright (c), by Zend Technologies

                      Thank you for the support

                          Miuruda-san

                          Run the command as root instead of Apache and see. Could be a user difference as in maybe Apache doesn’t have all the needed permissions.

                          Cheers.

                              I'm so furious at myself right now 🙁
                              Thank you for your help. That seemed to be the issue.
                              If you come to Rome in Italy contact me I'll buy you lunch 🙂
                              Grazie!!!

                              Write a Reply...