Ticket Creation via Email not working.

Tidepodracer

Earlier this month I was having no issues pulling in emails from users and having them translated into tickets. For some reason, this system stopped working. I have been trying to troubleshoot and cannot seem to find the right answers. Our osTicket was running Windows Basic Auth with no issues up until the 15th of May, but suddenly I cannot validate the user account is correct. (We are using on-premise exchange so Oauth is out as well) I am not sure if we have just not had the accounts configured to receive email and we just had a cron job fetching the messages, but would love some help.

KevinTheJedi

Tidepodracer

Please post a screenshot of Admin Panel > Dashboard > Information as that's always helpful.

Have you taken a look at your Admin Panel > Dashboard > System Logs for any Mail Fetcher errors, etc.? You can set your Admin Panel > Settings > System > Default Log Level to DEBUG and check your System Logs after a cron has executed to see if you see any Cron Job entries. If the cron was successful you should see such entries with the content of something like "Cron job executed [CLI]".

Cheers.

Tidepodracer

KevinTheJedi

I have taken a look at the system logs and nothing in there was out of the normal. we received a DB Error #1062, but this is something that we have experienced since deployment and has not been an issue before. I will check the debug logs shortly.

KevinTheJedi

Tidepodracer

I do notice that you are running v1.18 and not v1.18.1. Try upgrading to the latest, restart the webserver (and PHP-FPM if you're running it), and retest.

Also, are you using Authenticated SMTP? If so, are you able to Save Changes successfully in the Outgoing (SMTP) tab of the email with the status set to Enabled and authentication configured?

Cheers.

Tidepodracer

After changing to debug mode i am seeing Cron Jobs and Auto Cron executing, i am not seeing any failures or successes.

I will try upgrading it now to see if that can resolve the issue.

I thought we were running Authenticated SMTP but i am unsure at this time. When i tried to set it i received "5.7.3 authentication unsuccessful"

KevinTheJedi

Tidepodracer

Then that’s probably why outgoing mail is failing. Since you don’t have authenticated smtp configured it’s either using relaying or using the local sendmail/phpmail on the server to send out mail on your behalf. With that in mind your mail server probably doesn’t allow relaying or anything (most don’t by default nowadays). You can contact your mail admin to see if they can either provide you with the appropriate authentication information as well as the appropriate SMTP connection information -or- add an exception for this address to allow relating from your osTicket server. Authenticated SMTP is usually the more accepted and secure practice.

Cheers.

Tidepodracer

KevinTheJedi I am also looking at your response and saw your mention of "Then that’s probably why outgoing mail is failing" I should clarify that our outgoing mail is working perfectly fine and still delivering messages. It is our incoming mail that we are having issues with. The emails that a user send to us are not generating any tickets within our system.

Tidepodracer

Can I ask for further information as to what appropriate authentication information could be?

Also, when performing the system upgrade it mentions that the upgrader will be run automatically. I believe I pulled the right files into my server, but due to the documentation i may have misinterpreted some of the info it was suggesting.

KevinTheJedi

Tidepodracer

Ohhhh in your OP you said “… I was having no issues pulling in emails …” and my brain somehow connected that as fetching is working so must be talking about sending. I don’t know how it missed the very next sentence of “For some reason, this system stopped working.” which means it was working but now it’s not lol Totally my bad.

So if we are taking about fetching and the cron job shows in the debug logs then we know that’s running fine. So it must either be the mail fetch settings at the mailbox level and/or system level -or- maybe the authentication and/or connection information for the address.

Is fetching enabled globally? Go to Admin Panel > Emails > Settings > Incoming Emails > Enable Fetching, check (enable) the box for Enable, and Save Changes. Note, leave the box for the autocron unchecked (disabled) since you have a working cron job running. They can interfere with each other (eg. create duplicate tickets) if both enabled.
Is fetching enabled and configured at the mailbox level? Go to Admin Panel > Emails > Emails, click the email in question, click the Remote Mailbox tab, ensure everything is configured correctly (including auth), make sure Status is set to Enabled, and Save Changes.

Now, when you Save Changes on the Remote Mailbox tab with the Status set to enabled and authentication configured does it save successfully? If not you should see an error from the mail server/webserver that you can track down and address.

If all of that checks out then try running the actual command part of the cron job manually (or configured the cron command to output the contents to a file somewhere) and see if it returns any errors, etc. You should also check the web server, PHP, and MySQL/MariaDB error logs for any related errors.

Cheers.

Tidepodracer

KevinTheJedi They were both checked, I did uncheck the autocron though just to be sure.

Now for item number 2 I receive the attached error.
I looked at a few other posts prior to posting myself and did try some varying methods that worked for other users like adding domain\username instead of just the username.

KevinTheJedi

Tidepodracer

Then you should contact your mail admin as the information you have seems to be incorrect. Or maybe your mail server is denying the connection, etc. won’t know until you look at the mail server logs and see the reason for the failure.

Cheers.

Tidepodracer

Tidepodracer It shows this as the issue, but I set the username and password for this account and have tested the exact credentials to log into the mailbox and it worked. but for some reason within OSTicket it is not taking the credentials.

Tidepodracer

KevinTheJedi i'll get with our admin and see if anything has changed since it worked last.

Tidepodracer

KevinTheJedi After speaking with our mail admin, the only notable change was done 2 days after our fetch starting failing. I did just test and verify, using the exact same credentials entered within OSTicket i was able to log into the mailbox. Looking at the mailbox settings it is configured for IMAP

KevinTheJedi

Tidepodracer

Did you upgrade to v1.18.1? If so then have the admin look deeper on the mail server end. The error you are getting from the mail server says the info is not correct.

Cheers.

Tidepodracer

KevinTheJedi I uploaded all of the files for 1.18.1, but the documentation said that it would run automatically. It still shows that im still on 1.18.0 though when i just looked.

KevinTheJedi

Tidepodracer

Then your files are either cached and you need to clear it or you didn’t replace them correctly. All files in the upload/ directory replace your existing site files.

Make sure you take full backups of everything just in case you need to revert back.

Cheers.

Tidepodracer

KevinTheJedi Do you have a recommended method of moving all of these files over? I am running a CentOS7 machine and do not have access to cPanel.

KevinTheJedi

Tidepodracer

I wouldn't recommend CPanel anyways, it's usually trash lol There are many ways:

You can copy + force replace (eg. cp -aR /path/to/upload/* /path/to/site/)
- Be careful though this command forces the replace and does not prompt for each file. This can be dangerous if you don't know what you are doing. You can remove the a from -aR to not force but you'll have to confirm like hundreds of files; file-by-file.
You can completely move the new files and overwrite the existing files with something like the mv command (eg. mv /path/to/upload/* /path/to/site/).
- Be careful though as this does not keep a copy of the new files. It completely moves them from the upload folder.
You can rename the existing directory, create a new directory, put all the contents there, and copy over the include/ost-config.php file

There are other ways as well; just do whatever you are most comfortable with. Ideally you'd want to backup and move the old files away from the site directory, copy over the new files, copy over any plugins, and copy over the config file so there are no lingering old files, etc. from the previous version.

As mentioned above you definitely would want to backup the site files (you can zip them, copy/move them, etc.) and database (eg. by using mysqldump command - best option imo) just in case. This upgrade shouldn't touch the database at all (since it's a minor upgrade) however it's good to get in the habit of it now. If you were upgrading from 1.17.x to 1.18.x then it would touch the database and prompt the upgrader.

Cheers.

Tidepodracer

KevinTheJedi Thanks, i tried mv but for some reason it wasnt letting me replace existing files. Ill work and do the cp command today. All i am really worried about keeping is pulling the ost-config and our images folder. Worst case scenario will just be a quick restore.

KevinTheJedi

Tidepodracer

Maybe a permissions/ownership issue then. The user you are logged in as on the server may not have the appropriate rights to replace existing files.

Cheers.