I have been getting the following error on and off for the past two days since we changed from database to file storage using the available plug-in:subject of email: IOException: Unable to read resource contentbody of email: (root)/attachments//V/VpPCKItrlkG9iOxU2yyq4ZUdwYKwAug4:

Unable to delete file

/tmp/phpabdX9Y: Unable to move file

/tmp/phpUCRf77: Unable to move file

Note: there is nothing in the PHP logs at the time when we receive these error emails.  The errors are logged inside OST's sys log function

Here is my relevant OST Data:

osTicket Versionv1.9.5.1 (1faad22)Web Server SoftwareApacheMySQL Version5.1.73PHP Version5.3.3Ideas?  

    • [deleted]

    • Best Answerset by ntozier

    Ok, I think I have this all figured out - and I noticed that the switch to Windows Authentication (instead of "Anonymous authentication", using the built in username/password form in Osticket) was also causing problem for the "attachments on the filesystem plugin..."

    On IIS 10 when you have a website with Anonymous authentication and default application pool settings (which is how I originally had it set up) file reads/writes to the filesystem are performed under the context of the built in "IUSR" account, this also applies to temp files it tries to create in C:\Windows\Temp or whatever temp directory you have specified, and also in your nominated directory for the attachments on the filesystem plugin. If you check files in these directories you'll see they're owned by "IUSR".

    However when you enable Windows (HTTP) Authentication in IIS in conjunction with HTTP Passthru authentication plugin everything changes.

    By default the user authenticated via the browser (which is a domain user account) is now also the user account that IIS uses to read and write files, and if all of your users don't have read/write access to your temp directory and file attachment directory things break....and just giving full control to all users in those directories is probably a bad idea.

    So here's what I did to fix it. I don't know if this is the best way to do it (not an IIS expert as I keep saying, so take my bad advice with a grain of salt...) but it worked.

    What we want to do is have IIS read/write files on the filesystem as the same user no matter who authenticates via HTTP authentication - emulating the behaviour of Anonymous authentication. This leaves it up to OSticket to decide who has access to what file attachments/temp files etc. However you can't choose the IUSR account for this as it is a "special" built in account without a password.

    So I created a local (not domain) user account called "OSTicket" on the server with a strong random password, then in IIS you can specify that this is used for file access instead of the individual user accounts:

    Change physical path credentials to the account you created also entering the password:


    From now on this user account is used for all file reads/writes performed on behalf of OSTicket users, so permissions should now be set for temp and file attachment directories.

    To do this I added the local OSTicket user account to the local IIS_IUSRS group which is designed for this purpose, then adjusted permissions on the folders for this group.

    The Temp directory (C:\Windows\Temp for a default install) should already have full permissions for CREATOR OWNER, and you should make sure that the IIS_IUSRS group has special permissions "list folder / read data", "create files / write data", "create folders / append data".

    This allows the user to create files and modify/delete etc only files which it has created, similar to a sticky /tmp directory on Linux.

    In my file attachments directory for the file attachments plugin I simply gave "full control" to IIS_IUSRS.

    This seems to have fixed the issues with both file attachments and the temp file error I was seeing when pasting images into the editor. If you create a new attachment on a knowledgebase article then find it in the filesystem you'll find it's now created as being owned by the new user account you created rather than IUSR (anonymous authentication) or the requesting user. (windows authentication prior to this configuration change)

    The moral of the story is - if you are going to use the HTTP Passthrough plugin with Windows Authentication in IIS you have some extra configuration work to do in IIS to make it use only one fixed user account for file access/ownership and also need to adjust the permissions on your temp directory and file attachments directory to have things working properly with the user account you create.

Looks like a permission/ownership issue on the two folders mentioned.(root)/attachments/tmp

The attachments directory has 777 permissionsAll the sub directories within attachments are created by the OST FS Plug-in and each of those have a default permissions value of 355.  I'm guessing this is by design?  I could easily change all the sub directories (A,a, B, b, etc..) to 777 but the errors are only occuring on some directories and some files, so I do not think that's the fix?the /tmp directory in the root of our server also has 777 permissions.  I know it looks like a permission issue, but the error only seems to affect some files.I am worried that file attachments are getting lost or put in Linux limbo somewhere. Any help is greatly appreciated.Mark

13 days later

Same issue (or likely same root cause) here.It seems that despite being configured to save attachments to the filesystem, osTicket is saving new attachments to the database--and then it can't find them when it looks for them on the filesystem.Running this from the setup/cli folder of osTicket fixes it:sudo -u www-data php manage.php file migrate --backend D --to F(www-data might not be correct user on your system, though)

4 months later

Yep, I have the same thing, and your fix works. I'll have to set up a daily cron job.Or is there any way to track this down and fix?Yesterday I had 20 files migrated, out of 73 new tickets (all with attachements),all of them having been opened by fetchig a mail account.Or could it have anything to do with FS plugin setting, wheter it is absolute or relative path?

@[deleted]Please help us to help you by reading and following the posting

guidelines located in this thread: Please read before requesting assistance.  The more information you give us the better we will be able to assist you. Thank you.

latest 1.9.8.1 fresh install, no customizations,php  5.5.26, mysql 5.5.44, latest official FS pluginin settings tickets activated max 25 MB and store on FSAgent Maximum File Size:                     — Small —                                             512 kb                        1 mb                        2 mb                        4 mb                        8 mb                        16 mb                        25 mb                 Store Attachments:In the databaseFilesystem: /opt/osticket/upload/attachments            today I got 25 warnings, like on top of the threadSubject: IOException: Unable to read resource content(root)/attachments/C/CEzMPxhDX-WNFNZqFJ0pZPEEiM4oCSAQ to open for

readingbut nobody reports not beeing able to open a file,everything works but some file are saved to DB instead of FS (and none of the over 25MB)every ticket gets opened by fetched emailmigrated exactly 25 files from DB to FSphp manage.php file migrate --backend D --to Fand space for attachments are back at 0 MiBSpace Used7.25 MiBSpace for Attachments0.00 MiBAny other details needed?Thanks in advance.

You are not running the same version as the original poster.Your cron is running as what user?IS it the same user that your webservice is running as?What OS are you running?Are you running SELinux?  Suhosin?  mod_security?

Indeed more recent version, problem and workaround persist.Running on SME Server 8.1 (www.contribs.org) Centos 5.11.SELinux disabled, apache runs as www, cron likely not.Suhosin, mod_security not in the base distro, so no & no.Today I migrated 16 attachments out of 73 tickets total, 70 of them with attachments.Nothing in the logs, except the 16  IOException: Unable to read resource contentShould I perhaps switch from WARN to DEBUG level?Thanks.

If cron is running under a different username then make sure that it has permissions on your downloads folder.

The /opt/osticket/upload/attachments directory has 777 permissions and is owned by wwwSub directories are 355, files in these are 644 and everything is owned by root. Is this right?I migrated 33 attachments out of 96 total tickets today, every file has the same owner/right.I'd suspect the source code doesn't respect the storage setting under certain condition/load.

"I migrated 33 attachments out of 96 total tickets today"^this doesn't really tell us anything.Now hypothetically if you said you got 96 tickets today, of which X had attachments.Of those with attachments y were made with the web ui, and z were created via email.all of y didnt need to be migrated, but all of z did.That would tell us something.Webserver user may have access to the folders fine.Cron (commandline PHP) run as a different user may not.

php manage.php file migrate --backend D --to Fdoesn't seem to work in latest 1.9.9 version: "Please specify target backend for migration."backend command shows that both D and F backends are defined, script from 1.9.8.1 works

all tickets are opened via fetched email all with attachements (none via web) as stated in my very first comment

Other then saying perhaps you should try a different web host I don't know what to tell you.I've asked the devs to take a look at this thread.

I'd be glad if we could track somehow down the source of this (in the FS plugin or main code), I'm sure other people have this too. Thanks for your help.

I'd still recommend that you try a different webhost to see if perhaps it isn't the one that you are using now.

It's our server, Centos 5.11osTicket Versionv1.9.9 (a7d44f8)Web Server SoftwareApacheMySQL Version5.5.44PHP Version5.5.26PHP Extensionsgdlib Used for image manipulation and PDF printingimap Used for email fetchingxml XML APIxml-dom Used for HTML email processingjson Improves performance creating and processing JSONmbstring Highly recommended for non western european language contentphar Highly recommended for plugins and language packsfileinfo Used to detect file types for uploads

6 days later

actually since 1.9.9 only short format is accepted: php manage.php file migrate -b D -m F

lowering the number of fetched mails per minute from 5 to 2 seems to have fixed the problem of saving attachments to database instead of FS