File Upload Error 413 undefined for Staff when adding attachments

cooljoe04

I have two new installations in different environments that I am experiencing a similar issue with.
Initial/testing installation: osTicket on Windows10 + IIS direct from osTicket website.
Production installation: osTicket Awesome theme on WinServer2019 + IIS from osTicket Awesome theme's website.

From the public-facing website/form, I can create a new ticket and upload+attach a file to it as an anonymous user with no issue. The file uploads to the form, the ticket + attachment is submitted and created with no issue.

Once that ticket is created, and while logged in as a Staff member, I am unable to add an attachment to the ticket for a reply. I am given a "File Upload Error undefined 413" error message. I have checked/modified the php.ini file to enable file uploads, and set the max file size higher. I have gone into the osTicket attachment settings and verified that nothing is in the "optional" fields for allowing or blocking file types, I have also changed the max file size to reflect the modified php.ini settings. I previously had the system configured to save attachments to the database and have also tried changing it to save them to the local file system in a new folder I created with full read/write permissions as well, but nothing solved the issue.

I discovered this issue while trying to create an FAQ entry where I wanted to include some attachments and received the same error. I then tried attaching the file to a ticket and found it to have the same issue. The error is received while the site is uploading file to the site, prior to hitting the Submit button to create/modify the ticket or FAQ entry and occurs regardless of file type chosen (tested with pdf, jpg, exe). I have noticed that I seem to be getting a ticket lock expiring soon notice right after the error as well, regardless of how close I am to that timer expiration, but I don't know if it is related to this issue.

Exact error given:

File Upload Error
test_image.jpg
undefined
413

Any advice would be appreciated!
Thanks,
Joey

ntozier

There are a couple places where you can specify allowed file size(s).
The php.ini, the admin panel (ticket settings, and system settings).
Please provide us with the information from those three things.

cooljoe04

ntozier

I do not see anything obviously wrong there.

Re: The lock message that you are getting, have to checked your timezone in the DB, PHP, etc?

cooljoe04

Re the attachment settings: Neither do I (though I am admittedly a noob in this topic), and it is not something that always happens either. If I log into the ticket from the server, I can upload+attach the file to the ticket most of the time. If I do it from a different PC via the web, it keeps failing for me with the undefined 413 error.

Re the lock message: Time zone specified in osTicket was accurate. No default time zone was specified in MySQL, but current time was accurate with MySQL server. Specified default time zone in config file. No default time zone was specified in PHP, specified default time zone in config file as well. Verified time zone on OS was accurate. Rebooted server. No change. I have encountered the lock message almost always following the failed attachment upload attempt.

Daedalus01

I may be out of my element here, but have you checked the permissions on that temporary directory that you are using for uploaded files. You have C:\inetpub\temp\TempUpload specified as a temp upload folder. Maybe change that to C:\osTicketAttachments possibly? Files aren't able to traverse between the temp folder and the permanent folder?

cooljoe04

Daedalus01 I have now changed both the PHP upload directory and the osTicket upload directory to the "C:\osTicketAttachments" folder and ensured that it has full read/write permissions for "Everyone", "administrators", "users", "system", etc., but the results are the same. Unable to upload the attachment from a different PC. I also immediately receive the notice for an expiring ticket lock (on a ticket that was loaded 20 sec earlier, with a 5 min ticket lock) right after the failure to upload error message is displayed.

Daedalus01

On the off chance, what version of PHP are you using?

cooljoe04

Daedalus01 Started with v8.0, couldn't get things working properly out of the gate. Ended up with v7.3 instead.

Daedalus01

Thats what I was going to say. Currently the people that make OS Ticket don't have a production version of PHP 8.0 running. They only have an RC version that actually still hasn't been released.

You also have two other factors that you are throwing into the mix. Two different operating systems ( 10 and Server 19) and two different sets of main files ( main OS Ticket and Awesome).

Since you have IIS on both running, you could create test sites on both. That way you can narrow down if its an OS issue or if its Awesome theme. If you can get the base line system from OS Ticket to run on both, then its an Awesome theme version issue. If Server 2019 wont run the base line version, then its a missing preres, bad install/files or just that the Server builds are generally more strict than the client editions ( 10 ) of Windows and it needs some further tweaking. I am also not sure if OsTicket has been tested to run on Server 2019 either.

I'd also look at the IIS logs and see if something is being logged in there as well.

cooljoe04

I have been tweaking and testing around with this some more and it seems that anything below a 50Kb attachment seems to work. Anything above this will fail and generate the 413 error. This leads me to believe it is a file size limitation somewhere causing the issue and not a permission problem.

I have checked the php.ini's upload_max_filesize and post_max_size/increased them to 125Mb. I have also increased max_input_time and max_execution_time to 300 (5 minutes specified in seconds). Lastly, I have tweaked memory_limit to 256Mb from the 128Mb default just to see if there was any change. There was not. In the IIS 10 Request Filtering settings, I increased the "Maximum allowed content length (bytes)" to the field maximum of 4294967295, but there was no change. Anyone else have any ideas of things to try?

IssacChan

Hi Joe, I'm using almost same environment.
Server 2019, IIS 10, MYSQL 5.5, PHP7.2 for me.

You may change to PHP 7.2 for osTicket. I've tried 7.3, 7.4, 8.0 is not really support osTicket.
Also make sure you have install the plug-in for attachment and set it up.

cooljoe04

IssacChan I tried installing PHP v7.2 and updating the 4 fields mentioned above in the php.ini, but the results were the same. Below 50Kb files will upload, above sizes will not.

You said to make sure I have the plug-in for attachments installed/set up, are you referring to the osTicket plug-in, or something related to PHP/IIS/Windows/etc? I have the osTicket plug-in installed and pointed to save files to the "C:\osTicketAttachments" dir. That folder has read/write/execute permissions for the IUSR and IIS_IUSR group, which looks like it should be the one being used by IIS/PHP. Additionally, files are being written to that folder, so I am making the presumption it is working properly.

One thing I did find odd, but may be the way it is supposed to work, is that once a file is uploaded via osTicket and saved to the attachments folder, they are not retaining their file name or extension. Files will be uploaded from osTicket and automatically saved to a seemingly random subdirectory, with a seemingly random alphanumeric file name and no file extension. Example: A user uploads a test.txt file as an attachment, the file appears as "C:\osTicketAttachments\K\K2LPYTE37-luVBK_YeF_NJ_rp2jin1NQ" where the K subdirectory is automatically chosen/created, and the "K2LPYTE37-luVBK_YeF_NJ_rp2jin1NQ" portion represents the filename with no file extension. It is still a 1Kb file, but is not saved as a any specific file type. Opening the file with Notepad will still work/show the text, only the name/extension appears to be obfuscated/randomized/removed. Can this be turned off so that it is saved as the original file type at least, in case I want to manually backup the file elsewhere?

ntozier

cooljoe04 Can this be turned off so that it is saved as the original file type at least, in case I want to manually backup the file elsewhere?

No. This is a security enhancement to prevent people from browsing other clients attachments.

Daedalus01

cooljoe04

in case I want to manually backup the file elsewhere?

If you copy the entirety of the folder structure, then it will preserve the links that were created in the database so if you go to click an attachment it will pull the correct file.

IssacChan

cooljoe04
Try to read this document.

https://docs.osticket.com/en/latest/Plugins/Attachments%20on%20the%20Filesystem.html

cooljoe04

ntozier Understandable, but unfortunate. I got to thinking that I don't know whether or not the virus scanner software installed on that OS would scan the unknown file type for viruses/malware or not. Will have to do some testing in that regards.

typer139

I happen to be having the exact same problem.. I'm on Win Server 2012, IIS 8.5, PHP 7.2.2, MySQL 5.5, OST 1.15.5. I have the PHP ini max post and upload size set to 250M.. the attachment storage in OST set to 250 mb.. and somehow it doesn't abide by those limits. I can upload images without a problem.. I can upload 7MB videos without a problem. When I try a 30MB video, it fails. I have yet to find a fix..

KevinTheJedi

typer139

You may have updated the limit but it sounds like you have not updated the Maximum File Size setting for the Issue Details field. You can do this by going to Admin Panel > Settings > Tickets, scroll to the Attachments section, click on Config next to Ticket Attachment Settings, and update the Maximum File Size setting.

Cheers.

typer139

KevinTheJedi I would think that too.. but I think I updated every file size setting I could find..

User attachments..

Agent attachments...

PHP.ini...

.. and the IIS config..

The server is restarted nightly, so it's a fresh load of the web server, just to make sure all the settings were set properly. I've disabled and re-enabled the local file storage plugin..

There's got to be something I'm not setting..