Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

In this Discussion

osTicket v1.10 (stable) and Maintenance Release v1.9.15 are now available! Go get it now

Attachments issue in 1.9.15


I am having an issue with attachments to tickets in 1.9.15. This may have happened before in earlier versions but I don't know.

I can upload the files OK but when I come to download them all binary files are corrupted. Every file appears to be 2 bytes bigger than the uploaded version. This is OK for text files but not for binary files. If I do an octal dump of the uploaded file and the downloaded one, the first couple of lines of the original file are:

0000000 045520 002003 000024 004000 000000 056072 046133 143136
0000020 006062 000047 000000 000047 000000 000010 000000 064555

and those of the downloaded file are:

0000000 020040 045520 002003 000024 004000 000000 056072 046133
0000020 143136 006062 000047 000000 000047 000000 000010 000000

i.e. the two octal bytes 020 and 040 are being pre-pended to the file. The content of the downloaded file is identical to the uploaded one after that. Has this been noted before and how can I fix this?




  • Have never seen this before…also I don’t know why bytes would be added to the file…

    have you tried in all browsers and different OSs? 
    Also, any errors via Apache/PHP?
  • edited March 1

    Thanks for your response. I am investigating what you have suggested but could you answer the following.

    I am retracing my steps. I upgraded our original 1.6ST version as follows

    I downloaded osTicket 1.7.5 and 1.9.15 and now have two upload directories which I have called "upload-1.7.5" and "upload-1.9.15".

    We have a lampp installation on a Debian 6 server. The installation is in /opt/lampp/htdocs/csportal/osticket
    1. copied upload-1.7.5/* over /opt/lampp/htdocs/csportal/osticket/
    2. Logging onto osticket/scp requests me to upgrade which goes OK.
    3. Log off from osticket
    4. Take a dump of the new MySQL database and a copy of the new osticket directory (for my purposes)
    5. Copy uploads-1.9.15/* over /opt/lampp/htdocs/csportal/osticket/
    6. Log onto osticket/scp and follow the upgrade instructions. This goes OK.
    7. Take a dump of the new MySQL database and a copy of the new osticket directory (for my purposes)

    However, when I try to download an attachment that is a binary file from a ticket under the new 1.9.15 installation the downloaded file is corrupted. I can upload files to tickets OK but when I come to download the attachment it is alwasy corrupted

    Am I following the correct upgrade procedure?

  • edited March 1
    Everything looks okay in the procedure.  

    Although honestly I think that you could have skipped the 1.6 -> 1.7.x and just done 1.6 -> 1.9.
    If I remember correctly, in 1.6 attached files were stored on the file system and those were migrated into the DB in 1.7.  

    You could try installing the Storage :: Attachments on the Filesystem and migrate them back from the DB to the filesystem and see if that helps. 

    Meanwhile I brought this thread to the attension of the devs so maybe one of them will have seen this before.

    Oh, and were ytou seeing any PHP errors?
  • Hello,

    Many thanks,

    I've checked the Apache logs and there's nothing there. Unfortunately I did this quite a while ago and have only just noticed the download issue. I've no idea why I didn't notice it befor.

    I think I did the 1.6 to 1.7.5 to 1.9 route because it wouldn't work going directly from 1.6 to 1.9. I'll give it another go.

  • Hello,

    Success, I believe! There must be some discrepancy between the storage format for attachments in 1.7.5 and 1.9.* as directly upgrading 1.6ST to 1.9.15 seems to have done the trick. Attachments are now being uploaded and downloaded ok.

  • Huh... Thats really weird.  Well thanks for letting us know
  • Hello,

    Two more things about the Storage::Attachments plugin.
    1. The attachments from osTicket 1.6 still exist under osticket. Will these be over-written by enabling the plugin?
    2. If installed and enabled does that mean all future attachments will be stored on the file system instead of in the database?
  • 1. No.
    2. Yes.

    As a side note if you are moving attachments to the file system you should probably migrate the ones in the DB to the file system as well so that you have them all in one place.
  • Many thanks. I have just downloaded the plugin:

    v0.3, released Apr 2 2015

    Is that the latest one?

  • Looks like it from my perspective :)
  • edited March 13
    I'm sure I've installed it correctly and configured it OK. See the two attached screen shots. However, when I upload a file it's not on the file system so it must be in the database. The specified attachments directory has read and write access for the web server. The old attachment from the 1.6 version already existed in the /attachments/ directory. Is there anything else I need to do to ensure that
    1. these are used instead of the ones in the database?
    2. that new uploads are stored in the filesystem
  • After you upload, configure and enable it.
    You still have to go to:
    Admin panel -> Settings -> System
    scroll to the bottom.
    Under "Attachments Storage and Settings:"
    set "Store Attachments:" to the new option.
  • Thanks for your quick response. Sorry, I had already done that. I followed the instructions on

    which I found on

    I tried initially changing the permissions on the attachments to 777 but still no joy. You say on that post

    "did you migrate the files from the DB to the file ssytem after installing and enabling?"

    How do you do that?

  • You would use the manage.php script at a command line.

    php setup/cli/manage.php file migrate --backend D --to F
  • Thanks. I'll give it a try. Will any/all files that are already under attachments (from 1.6 installation) be overwritten by this process or, if they already exist will they remain unchanged?

  • Hello,

    I need to revisit the original issue. I didn't have a lot of joy with the Storage::Attachments plugin but I will come back to that. I was a bit premature in saying that my original issue of uploaded files being corrupted had been resolved. If I upload any file two bytes are prepended to the file. This is OK for text files and doesn't always seem to affect, say, PDF files. However, it always seems to affect MS Office and LibreOffice documents. I have tried to attach a LibreOffice spreadsheet file (.ods extension) to this post that was uploaded and then downloaded from a ticket but am not able to: when I select the file I get an error as in the attached message. Could this be a related issue
  • Not sure the error message got attached to the last post so attaching it to this
  • @catfood

    Yes, that can very well be the issue. Anything Windows is known to not play well with osTicket (or anything else for that matter). I would try doing a test upgrade to v1.10.1 to see if v1.10.1 fixes this. If that doesn't help test with non-windows files to see if you get the same results.

  • edited March 23

    Thanks for taking the time to comment but, and I hope this doesn't sound rude, that is not very helpful. There are a lot of MS Office and other Windows-produced binary files out there. However:
    • The .ods file I was trying to upload was created in LibreOffice on Linux.
    • The issue with corruption of uploaded files has only started happening since I upgraded from 1.6ST to 1.9.15 and the files are stored in the datbase.
    It is inconceivable that uploading and then downloading binary files should be an issue at all. Many of our customers upload MS Office files, PDFs, images etc. and this has never been an issue with 1.6ST where they are stored on the file system.

    What I would really like to be able to do is to upgrade my 1.6ST installation leaving the attachments on the file system, i.e. not storing them in the database, and for all subsequent uploaded files to also be stored on the file system. There are two reasons for this.
    1. Storing them in the database makes for a very large database
    2. Leaving them on the file system means that there is no need for manipulation of the source files.
    Having to use the Storage::Attachments plugin to reverse the process of storage in the database seems to me to be a retrograde step. It is also not one I have yet found successful vis-a-vis extracting the existing attachments from the database. I will need to come back to this.

  • edited April 16

    I really would like to get this sorted soon. On our test
    1.9.15 installation it seems that every uploaded file has the two octal
    bytes 020 040 prepended to it when downloaded. Interestingly, if I
    respond to an existing customer ticket and attach a file to the response, the file is
    attached to the email that the customer receives and can be opened
    successfully by the customer.

    It seems (to me) that the issue is
    with the download functionality of the file from the database. Any ideas
    would be most welcome.

  • @catfood

    Without any errors or test attachments/test cases I cannot help as there's not enough information. ALL attachments on my system are uploading/downloading just fine no matter what type of file it is.

  • edited April 16
    I'm trying to upload a 1.78Mb zip file but get the error that it is too big (max 2Mb)
  • What I'd like to know is why every file, whatever type, always has the two octal bytes 020 and 040 pre-pended to them. If, for example, I save a file rather than try to open it with the appropriate application (e.g. Word) as, say


    the file won't open. If, however, I run the command

    dd bs=1 skip=2 if=testfile.docx

    the file testfile-2bytes.docx opens fine. This works for all file types.

    I can attach more files when you tell me how to upload files that are apparently within the limit but get rejected because it is too large.

  • image

    Did this get uploaded?
  • Note: When I make a post to a ticket as a member of staff all attachments I add get attached to the email that teh customer (user) receives. Is there a simple way to allow all attachments added by a customer to get emailed to our customer support email address?


  • Trying to upload a file called BicycleTools.docx but am having problems. Help please
  • bicycle_image.png
  • After all that I have managed to upload two files.

  • Hello,

    My apologies for not answering before but the issue was all of our making. An authentication program we are using for single-sign-on with our customer portal had the two octal bytes 020 and 040 pre-pended to the start. These were getting pre-pended to each attachment.

    Sorry for wasting your time.

Sign In or Register to comment.