Print Ticket doesn't work for Agents, no errors

TPE

1.15.3.1, php 7.3

Print Ticket was working, and is no longer working for us as a standard Agent, nor for an Administrator

There are no errors on the Admin Dashboard screen, no PHP errors, and no errors on the Browser after pressing the print button (I have PHP.INI set to display errors)

The permission on the /tmp directory is still 755 (is this the correct permission)?
The owner of /tmp is admin:admin (should this be admin:nobody?)
These owner/permissions seem to work for another instance of OSTicket that we have running.

Is there some documentation that describes the prerequisites for this to operate successfully?

Update - seems related to print with Attachments. Prints fine without attachments, doesn't print (and no error) when printing with attachments.

ntozier

OS?
Webserver?
PHP errors?

TPE

Part of the problem is that I don't see any errors anywhere: the browser is loaded with a blank page whether I enable PHP errors on-screen or not. There are no errors recorded on the OSTicket Dashboard either. Its just silently doing nothing.
At the moment, we can't get it to generate a ticket for Admins, for Agents, whether there is or isn't attachments. Nothing works. We can create tickets with or without attachments, and view attachments.... but we just can't print.

OS & Webserver:
We're running this on a Linux GoDaddy VPS; CentOS 7, Apache/2.4.51 (cPanel) OpenSSL/1.1.1l mod_bwlimited/1.4

This is killing us, and we're prepared to pay a professional to get it resolved. Help?

Thanks!

KevinTheJedi

@TPE

Try the below steps:
1.) Create a new directory called osticket_tmp somewhere (ideally outside of your HTML directory) and give it 777 permissions (just to start with).
2.) Open include/class.pdf.php, go to line 76 (here), and change sys_get_temp_dir() to '/path/to/your/osticket_tmp' (with the quotes).
3.) Retry printing a Ticket.

If that works adjust the permissions on the new osticket_tmp directory to something like 755. Just make sure the system is able to delete the temporary files it creates otherwise this directory will grow in size each time you print.

If that still doesn't work your host has some funky restrictions and it'd be worth contacting their support to see what's causing the issue.

Cheers.

ruizgo

KevinTheJedi Thank you very much for your post, it worked for me. I'm using osTicket v1.18.1, I took advantage of the directory that I had created to store the attachments and it already had the necessary permissions.

TPE

Trying to create a temp folder with additional write permissions didn't change the behavior.
Even so, I learned a little more:

I have a specific test ticket that has one attachment (an .mp3 file)
I can print this specific test ticket without attachments (PASS)
I can click on the attachment and the attachment will download (PASS)
When I click on "print with attachments", it doesn't work (FAIL)

This is what I see on screen:

And I get a corresponding email with this message:

eMail Subject: IOException: Unable to read resource content
eMail body: (root)/tef_artifacts/u/ub1iOX6qrXAygg8Gu9tdx18C1Y0Z7z1g: Unable to read from file
http://xxredactedxx/service

We don't have an abnormal hosting issue - the OST implementation worked all the way up until we noticed some file permissions change in our public_html directory (perhaps a virus), and we restored all of the permissions that we could identify outside of OST. We think that our problem is that we haven't restored the permissions WITHIN OST. Is there a way to restore all the permissions throughout the implementation?

ntozier

This looks like a permissions/ownership issue some where to me at one of the places here🙁root)/tef_artifacts/u/ub1iOX6qrXAygg8Gu9tdx18C1Y0Z7z1g

TPE

Directory "u" is empty.
The filename "ub1iOX6qrXAygg8Gu9tdx18C1Y0Z7z1g" doesn't exist anywhere in our directories.

My assumption is that this path represents the ticket's attachment (mp3 file in my example above)?

As I described above, I can click on the attachment link in the ticket, and it will locate and download the attachment to my downloads folder normally.

I'm starting to wonder if the system is choking while printing an .mp3 ? Is there something to suppress non-printable attachments? We rely heavily on inbound voice messages from our voicemail system.

Also, do these permissions look generically accurate to you? Do you expect to see 1755, 1355, 0755, and 0644 (on the .keep file)

ntozier

That looks pretty standard to me. Maybe what's happening is the attachment is getting written in the PHP temp directory, and when when PHP goes to move it to its final home the permissions are choking. This resulting in the cannot read the file... since it doesn't exist.

TPE

Whats the fix?

ntozier

Make sure that the PHP temp directory has the proper permissions.
Since this is hosted you would likely need to talk to the host for support on that.

TPE

What should the PHP temp directory permissions be in order to work with OST?
Ours is 755, owner = redactedUserName:redactedUserName

Our sites aren't managed. We operate our own VPS... but either way, I'm unclear what you're recommending that we look for from a "hosting" perspective? What should we find and fix?

Also, I've asked several times how to verify all the permissions on all the files and folders. Is there a tool or utility that either "verifies" or "restores" the installation files?

We're desperate - is there any paid support channel that we can tap to get this resolved?

Thanks in advance.

ntozier

my PHP temp folder has the same ownership and permissions that my destination has. Which seemed to fix some issues once upon a time.

There is a paid support service (I have not used it)
https://osticket.com/professional-support/

TPE

ntozier
What is "my destination"? What should I be comparing? /tmp to ???

TPE

How do we verify all the permissions on all the files and folders. Is there a tool or utility that either "verifies" or "restores" the installation files?

ntozier

You said your destination was (root)/tef_artifacts/

the webserver user would need to be able to read and write to it.

TPE

The permissions on (root)/tef_artifacts is 755.
Recall: I can successfully upload an attachment to a ticket, and successfully fetch (download) an attachment on a ticket... but I can't print a ticket with attachments.

ntozier

And what are the permissions and ownership of your PHP temp dir?

Also take a look at this post.
https://forum.osticket.com/d/93500-printing-tickets-does-not-work-in-1-11-stable/21

TPE

From above:

Ours is 755, owner = redactedUserName:redactedUserName

Regarding this other support ticket... we don't see any errors anywhere (see my OP).
I created the temp.php file that will echo the location of the system temp directory.
The output is correct:

[redactedUserName public_html]$ php tjtest.php
/tmp

We successfully upgraded our implementation to 1.15.4 today, without a change in behavior for printing tickets that contain attachments.

TPE

We still don't have a resolution for this.

After upgrading and 2 more months of experimenting, we can't find a consistent reason why some tickets aren't printing.

Do we have any more options or troubleshooting procedures?

Thanks in advance.

KevinTheJedi

@TPE

Your initial issue is that one of the attachments doesn't exist (as you mentioned) so when you go to print with attachments it goes to grab the file and fatally fails as it’s not found. Why doesn’t it exist? That’s unknown at this point. It could be permission/ownership issues, it can be /tmp dir issues, it could have been deleted on the server, it can be all sorts of things. If the majority of attachments are being saved to the file system successfully then you really need to investigate on the server end of things to see why certain files don’t exist when others do. Are there intermittent issues happening that is causing this? Is there something cleaning the disk and removing files unintentionally? There are just so many possibilities.

I would say if you have a current example of this then check a recent backup of your server (or whatever drive that has the attachments) to see if it ever existed and vanished at some point or never existed at all. This can help you narrow down where this is stemming from.

I can say from the software side of things it doesn’t really make sense that most of your attachments are saved just fine and some are just plain missing. I mean in normal situations it should have the same connection, same path, same permissions every single time.

Cheers.