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
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
There is three processes who manages those attchements. What user are they. run migrate from console - probably rootpiping og e-mail - I'm not sure what user, could be root, could be web user. WEB GUI entred attachements. I Saw that the attachments folder there where plenty of folders owned by root. I guess there is some issues for other processes who are not root to put anything into those folders. 1. Set the web user as owner for all files in the attachment folder. Recursively. 2. Put the correct permissions of all subfolders of attachment folder. If you do some migrations from root user, re-do the steps above. - Hope this helps - - Ole
I've started seeing this out of the blue several months into use of OSticket, although I'm running on Windows Server not Linux.
Every time I drag and drop an image into the editor in a ticket, knowledgebase article etc I immediately get an email warning with subject "IOException: Unable to read resource content" and body: "C:\Windows\Temp\php952F.tmp: Unable to move file"
Initially PHP's default upload_tmp_dir was C:\Windows\Temp - Ok, so IIS may not have sufficient privileges there, so I created a directory beside the osticket www directory and changed php's upload_tmp_dir:
upload_tmp_dir E:\inetpub\php-temp
This setting appears correctly when running phpinfo().
However I'm still getting the error and I notice that although the drive letter changed it's not using the path I specified in the php config ??!
"E:\temp\php952F.tmp: Unable to move file". So I don't know how OSticket is generating this path which takes notice of the drive letter specified in upload_tmp_dir but ignores the path ?
Anyone have any clues on this one ? The strange thing is that I've only started seeing this about a week ago and I haven't made any changes to OSTicket or the server...
Maybe try replacing the code with the full path including drive letter. If you do this it should use only that path. It does not create its own path. It uses what it's given.
Cheers.
I found it was getting E:\Temp from the TEMP environment variable on the system...
I've made the following changes to php.ini:
sys_temp_dir e:\temp\
upload_tmp_dir e:\temp\
session.save_path e:\temp\
sys_temp_dir was empty before in phpinfo(). session.save_path was pointing to c:\windows\temp.
I've also added CREATOR OWNER full permissions on e:\temp and IIS_WPG full permissions on e:\temp. (I think this is the right account - I'm not an IIS expert, more of a Linux guy...)
Still the problem remains when pasting images into the editor - I get emailed an error every time I paste an image.
However images do still go into the ticket/knowledge base article and stay there despite the errors.
I have also always been using the "Attachments on the filesystem" plugin with a path of E:\inetpub\osticket-attachments - not sure if this is relevant although earlier posts suggest it might be.
I suspect this problem may have been there all along but I may have made a config change recently that causes errors to be emailed me to now as I don't remember osticket ever emailing me system errors prior to this.
Windows is notorious for putting random characters and bits in the clipboard when copying an image, tables, etc. I don't know why they try to be different so much...anyways, try saving the image somewhere like Notepad or something, copy it from there, and paste to see if you get the same issue. If so, open the image with Image Viewer (or whatever it's called) and copy from there and test.
Disregard that I read it initially as copy/pasting but you're dragging/dropping. @ntozier have you seen this before?
Cheers.
I am actually copying and pasting (sorry for being misleading in my first post, not sure why I said drag and drop!) either using Shift-Windows-S to snip an area from the screen then pasting it directly in, or copying from something like paint, then pasting into a knowledge base article or ticket. I don't use drag and drop from a file.
What I don't understand is I've been doing this from day one a couple of months ago and am only getting emailed this error for the last two days - and I can't think of any changes that could be affecting this, also the process of pasting the images in still works fine and after saving the ticket or knowledge base article they are there - it's just an annoyance that I keep getting email alerts.
The error itself is a bit ambiguous as well making it hard to troubleshoot - the subject says unable to read resource content (and yet the image pastes into the ticket OK...) while the body says "unable to move file" but doesn't indicate whether the temp path given is the source or the destination of the move...so I don't know where it might be trying to move it to or from.
I also don't see any file appear in the temp directory when the error occurs.
Ah okay, when you said Every time I drag and drop an image into the editor I thought you meant literal dragging and dropping.
Yea that’s weird for sure. Did the browser get updated or something? Was there a windows update? If it was working before and all of a sudden doesn’t it sounds like something did change. osTicket doesn’t update on its own so if you didn’t touch it I doubt it’s an osTicket issue. But you never know. Try a different browser and see?
Cheers.
Ok it's looking a little bit like a switch to using Windows integrated authentication a couple of weeks ago may be the underlying issue - when the temp file is written by IIS it's written to the temp folder using the permissions of the user who is authenticated via the browser rather than the ApplicationPool user, and this user doesn't have correct permissions for the temp folder. Doh!
Will need to look into how to change this in IIS, again not an IIS expert....
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.
