PHPJunkyard support forum

Hi all - I've been using HESK v2.5.5 for close to a year and it's been working great. I was successful in setting up email piping so that all customer inquiries from our OpenCart webstore automatically create a ticket in HESK. This was huge - before, it was just a hot mess of random emails in one of my inboxes.

Over the last week or two, I've been getting more and more complaints that emails are not getting through. I sent some test emails and found the same thing - piping was no longer working. I did some digging and found that somehow the \inc\mail\hesk_pipe.php permissions got changed from 755 to 640. As soon as I changed them back, it started working as normal. The bounceback error email I got is:

This message was created automatically by mail delivery software.

A message that you sent could not be delivered to one or more of its
recipients. This is a permanent error. The following address(es) failed:

pipe to |/home/***/public_html/support/inc/mail/hesk_pipe.php
generated by ***@***.com
(ultimately generated from ***@***.com)
local delivery failed

The following text was generated during the delivery attempt:

------ pipe to |/home/***/public_html/support/inc/mail/hesk_pipe.php
generated by ***@***.com
(ultimately generated from ***@***.com) ------

Could not exec '/home/***/public_html/support/inc/mail/hesk_pipe.php'

Unfortunately, it's happened a few times since then and I have to manually go in and change the permissions back. I upgraded to Patch #5 to see if that would help at all, but I checked again this morning and it was back to 640. I switched it back to 755, but need it to "stick" at 755.

I've been on hold in the IVR of my hosting provider's support line for almost an hour now trying to see if this is something on their end and/or if they have any ideas on how to resolve. Would a newer version of HESK solve this, or is this purely something the host (Arvixe) is doing? I'm running on a shared server plan, MySQLi is 5.2.17 and MySQL version is 5.5.42-MariaDB-cll-lve.

Any help would be greatly appreciated!

Thanks!

That is indeed something that needs to be attended to/fixed on the server side. HESK does not change any file permissions.

My best guess is your host is running some sort of a "security" scanner fixing "insecure" script permissions (I have "insecure" in quotes because it's not really insecure if used properly and actually required to be set like this on your server for pipe to work).

You should ask your host to exclude the "hesk_pipe.php" script from any such scans and explain to them that the script is being called via CLI so it needs to be set like this.


P.s.: 2.6.x has been out for over a half year now, might be a good time to update

Thanks very much Klemen! I appreciate the feedback and and will pass your notes along to my hosting provider to see if I can get this resolved. I had a feeling it was a hosting-side issue, but my provider's "support" (and I use that term very loosely) has yet to provide feedback.

An upgrade to 2.6.x is definitely in the cards - I've got a few other upgrades in process now, but once those projects are done, I'll be bringing HESK up to current. It's a great app and has been a lifesaver managing the increasing inflow of customer inquiries!

Thanks again...

Jason

Well, I don't seem to be making much forward progress on this, and continue to have the permission downgrade issue.

Here was the less than useful response from my hosting provider (Arvixe) after waiting almost two weeks for the ticket to be assigned...gotta love when EIG buys a company and guts the support staff:

Hello,

Thank you for contacting support.

Arvixe does not run scans of any nature on your files. There is no automated background process or cron job running that is or has the ability to change your file permissions. You can set your file permissions to any values, and they will remain that way until either you or a script in your account changes them again.

You can also try setting the files permissions to 777 to see if those stick better.

Please feel free to reach out to us with any additional questions or issues, and we would be more than happy to assist you further.

Regards,
Michael H.
Support Team

Technical Support
Arvixe Web Hosting
http://www.arvixe.com

I tried setting file permissions to 777 this morning, and at roughly 9AM, they flipped back to 640. Any thoughts on what could be causing this to happen? I don't have any other scripts or cron jobs running, and I'm still of the mind that it's a server-level issue. That said, I haven't been able to reactivate HESK until I'm sure those permissions will "stick"!

Thanks...

Jason

Do you know how often the file permissions get reset? A really "hacky" way to keep them to stick would be to create a cron job that runs every minute or so to simply execute a chmod command against the file to keep it at 777. I've never tried it so I can't guarantee if it would work at all.

Thanks Mike! I'm not 100% confident, but it seems like it's right around 9AM ET each day. I'm going to try to narrow it down further by logging when I change it (or notice if changing back), but I have a feeling it's some automatic scan that Arvixe runs at 9AM ET each day. Odds are good I may be moving away from Arvixe sooner than later (and will upgrade to HESK 2.6x when I do!), but would like to try to patch it together long enough to keep things running.

I'm "code challenged" when it comes to most of this stuff, but does this look like it might work?

/bin/chmod 755 /home/(HOMEDIR)/public_html/support/inc/mail/hesk_pipe.php

If I can narrow it down to only happening once a day, I'll just have it run the cron right after 9AM; otherwise, might need to have it check every minute. Still a chance someone might get their email bounced, but a lot less likely!

Thanks...

Jason

Just for grins, I tried that cron command on an every minute basis and it works like a champ! I've purposely switched it down to lower permissions, and within a minute it's back to 755. Hack or not, this hopefully will allow me to start using HESK again until I can get away from Arvixe!

I'll update if I hear anything different from the host (i.e. oops, we actually ARE running security scans ) or if the chmod cron blows something up, but so far, so good!

Thanks again...

Jason

Glad to hear Mike's hack worked for you.

But you should definitely ask support to raise your ticket to a higher lever support team. File permissions don't change by themselves

Well, the good news is that the "hack" is keeping file permissions at 755.

The bad news is that with the correct path in cPanel email forwarding and piping turned on in HESK, emails are getting lost somewhere along the way. No bouncebacks, no tickets created in HESK, just....nothing.

I confirmed the hesk_pipe.php permissions are still set to 755. There are other files in there - email_parser, etc - that are all set to 640...do any of those need to be CHMOD'd to 755 as well? I setup piping in cPanel the way I've done previously, and get the "green checkmark" to the file path.

I was really hopeful that fixing the hesk_pipe.php permissions issue was going to the be the easy fix, but it appears not. Any other thoughts would be greatly appreciated!

Thanks...

Jason

Are you testing with unique emails? Make sure you change the subject/message for each test email or they will be ignored by HESK.

Hi Klemen - pretty close guess. I was banging away with test emails that simply said "Test 1", "Test 2", etc., but with no text in the email. I did catch later today that other emails being forwarded to HESK seemed to be creating tickets fine, so just sent an email with a longer subject line and some text in the body of the email.

VOILA - TICKET! Apparently the machine is smarter than the guy behind the keyboard.

With Mike's hack keeping permissions in check and piping back alive, I think we are back in business. I'm going to upgrade to 2.6.5 to coincide with the hosting move anyway, but this should tide us over for another month or two until that happens.

Thanks again guys...really appreciate the assistance!

Jason

@ rotaryracer , I know this is an old post but I'm hoping you'll notice it... Was there a suitable solution from your host? I am experiencing the same issue from A Small Orange. The system works beautifully until it doesn't and I go into hesk_pipe.php and realize the permissions have been changed from 755 to 640 mysteriously.

As a follow up... I have spoken with support at ASO, they, like the original poster advised they didn't have any security scanning routines changing permissions on my files. They also looked through all the cron jobs on the account, and nothing appeared to be causing it there either. He then changed the permissions of the hesk_pipe.php file to 740. I sent a test email and it indeed came through, however, I'm skeptical as to whether that sticks. Our chat was turned into a ticket, so eventually I may learn more.

As an aside, I installed Hesk with cPanel/Softaculous installer, and I believe I chose to have backups made - could this be the issue?

Facts:

- permissions don't change themselves, something is changing them
- there is nothing within Hesk that wold do that
- lower-tier support staff are most likely not aware of everything that is going on the server

Whatever is changing them, it's probably happening around the same time every day. You should figure out approximately at what time this is happening then ask support what cron jobs are being run (or still running) at that time. They should escalate the issue to a senior server admin, (s)he should know what is actually running in the back-end.

You can even create a simple "test.php" file (completely unrelated to Hesk) in your website, chmod it 755 and document it (screenshot or something). Then wait for and document the automated change and present it to support.

Thanks for the response Klemen, and I have no doubt this is something on the server end of things. I'll try to track down what time it changes as I wait on the response to the ticket that was created. I may try the workaround/hack suggested and run a cron that simply changes the permissions to 755 regularly.