Mail fetching no longer works

jluck14

Hello. I am running osTicket 1.18.3, with apache on ubuntu server.
Today, my oAuth token stopped refreshing, and even though I reauthenticated using the MS flow successfully (which refreshed the token for a few hours), it will not auto-refresh.
On top of that, mail fetching stopped working even when it has a valid token. Setting the system log to DEBUG does nothing, and pretty much nothing hits the log. Cron is running properly too. Please help.

ost_email_account table shows this

Credentials: Required option not passed: "access_token" 2026-09-11 19:25:37
even though the token is current. that's the only error i've been able to find.

KevinTheJedi

jluck14

Can you show the email’s OAuth2 configuration, specifically the Scopes?

Cheers.

jluck14

Hello, here are the scopes:
offline_access https://outlook.office.com/IMAP.AccessAsUser.All https://outlook.office.com/POP.AccessAsUser.All https://outlook.office.com/SMTP.Send

Additionally, an image of the rest of the config (left out client ID and secret)

I do notice that the scopes are using outlook.office.com ... which is interesting because we use GCC High, which usually has .us endpoints. It may be irrelevant though, as my predecessor set it up this way and it was working for a year.

jluck14

Additionally, if it's relevant, this is a shared mailbox that a different identity is authenticating for, in order to read and manage its mail.
I've checked the sign-in logs, and note that it's successfully logging in to 'osTicket Oauth2 e-mail integration'.
This leads me to believe something may have broken both with the cronjob (which never appears in osTicket logs, but does in syslog). and with the token refresh (which isn't happening on its own anymore.)

KevinTheJedi

jluck14

If you use GCC high you definitely need different endpoints. Everything (including scopes) have “.us” rather than “.com”. Also the resource details endpoint is: https://outlook.office365.us/api/v2.0/me

Cheers.

jluck14

Hello Kevin,

Thanks for the prompt reply. So the scopes would all just change from .com to .us? No further changes like https://outlook.office.com --> https://outlook.office365.us?
And I am not seeing a spot to input resource details anywhere in oAuth2 config...

jluck14

I tried changing the scopes to . outlook.office365.us ... was able to authenticate and retrieve a token, but mail fetching / tickets still seem to be busted.

I found from this thread https://forum.osticket.com/d/106926-oauth2-authorization/8
that resource details was removed in an update... Additionally, the scopes should apparently end in .com , so I think they were correct to begin with (explains why this was working for a year until just the other day) ... So I am a bit lost as to why the token auto-refresh is suddenly broken, and cron jobs that are executing don't show up in the osTicket syslog.

Thanks, and please let me know if there is anything else I can check.

KevinTheJedi

jluck14

That's odd because sources online say not to mix .us endpoints with .com scopes. 🤷‍♂️

I would assume due to busted scopes. When something isn't correct you may be able to authorize but not refresh. Same exact thing happened (ie. authorization worked but refresh didn't) when people were using the old scopes before the full "outlook.office365.com" scopes were forced during the big API change a few years back.

Cheers.

jluck14

Kevin,

It is quite odd. I've stuck with the updated .us scopes, as it just seems more correct. I did notice, that in the ost_config table, we do have this url, set for urlResourceOwnerDetails : https://graph.microsoft.com/v1.0/me
Could this be the issue? I know the option to change this graphically was removed in an update, per that forum post I'd linked... But there was a lot of mention of using https://graph.microsoft.us/v1.0/me or https://graph.microsoft.us/v2.0/me ... Not that it was relevant to their issue. At this point grasping at straws.

KevinTheJedi

jluck14

You can manually update it in the database 100%. We removed the ability to edit it because too many people couldn't grasp that you almost 99% of the time don't touch the resource details endpoint. We had so many reports and support calls just for us to switch that one endpoint back to default. We will eventually add a GCC High option for MS so that it has all the correct info (even un-editable ones).

Cheers.

KevinTheJedi

jluck14

I can't tell if https://outlook.office365.us/api/v2.0/me is still appropriate or not since I haven't had a GCC High instance to test with since the whole API change a few years back so it could very well be https://graph.microsoft.us/v1.0/me instead.

Cheers.

jluck14

Kevin,

Thanks for mentioning that, I will try v1.0 if the emails don't fetch within a few minutes.
I'd updated to https://outlook.office365.us/api/v2.0/me , rebooted the whole server, sent in another test email.
Interestingly, while messing around with fetching (disable and then enable), I got a very quick error something to the tune of 'streamconnecterr, could not connect to outlook.office365.us' ; I haven't been able to reproduce it yet. Wondering if maybe those new scopes are no good, though possibly that was just a fluke.

I'll see if changing the resourceownerdetails to 1.0 works as well, and let you know.

jluck14

Tried swapping the API url to 1.0 and rebooting, disabling and re-enabling mail-fetch, no change.
Tried leaving the API url as 1.0 and setting the scopes back to .com , no change.
At this point I am wondering if we're barking up the wrong tree...

I do note that trying to run my cron job for osTicket manually using sudo -u www-data /usr/bin/php /var/www/osticket/api/cron.php yields:
sudo: unable to execute /usr/bin/php: Operation not permitted
So perhaps something broke the cronjob permissions for the www-data user?
No idea how that would have happened. Nothing has been changed with that since this was first set up.

EDIT: Still have plenty of entries for www-data running the cronjob.
2026-09-14T14:32:01.059382+00:00 iecapp1100 CRON[9119]: (www-data) CMD (/usr/bin/php /var/www/osticket/api/cron.php >/dev/null 2>&1)

jluck14

Also got this with strict matching unchecked once, ran through verification again, and was able to successfully get a token. Apologies for flooding you, just trying to provide as much info possible to fix this bug.

At this point, I'm about ready to discover everything needed to backup my tickets, users, and configs, and just reinstall osTicket fresh 🙁

jluck14

Kevin,

Feel free to close this ticket for now. Through further digging, the execution of /usr/bin/php was the issue after all, and was silently failing the cron, which in turn failed automatic token refresh, and mail fetching.
Our application control software (ThreatLocker) was blocking the execution of /usr/bin/php , (without notifying us at all) meaning that nobody could run the job.

Sorry for wasting your time, and I thank you for your assistance in troubleshooting!