4938 Posts in 16827 Topics by 1490 members
|Go to End|
15 December 2010 at 11:01am Last edited: 15 December 2010 11:04am
Got a problem with my IIS install of SS 2.4 when trying to upload images via "Files & Images" - The uploaded image displays as a 'broken link' image.
The problem occurs as follows:
In Files & Images the image appears to upload without a problem (no error messages) and when you click to view the file you can see the "resampled thumbnail" version created by SS.
When you then go to the WYSIWYG editor to add the image you can see the resampled thumbnail version in the Image insertion area on the right. However, once you insert the file into the page it comes up with a "broken image" link. If you publish the page the image is still not appearing in the front end, so its not just a problem with the WYSIWYG editor.
When I uploaded files via FTP and then used "Look for new files", there was no problem at all. They display fine.
You can see a screenshot of it at: http://i319.photobucket.com/albums/mm453/linseymiller/SilverStr/SS-Upload-Screenshot.jpg
Here's what I've done so far:
1) checked the URLs: The resampled thumbnail and the "original" file both exist and the system is providing the correct urls.
If you call the thumbnail directly via the URL it displays, however calling the "original" by its URL gives a 500 Error, e.g.
...some-domain.com/assets/Uploads/_resampled/StripThumbnail-tlogo-christies.gif (shows resampled image)
...some-domain.com/assets/Uploads/tlogo-christies.gif (500 error)
2) Downloaded both files. And they both 'look' fine, so nothing is happening to the original file 'physically' to stop it displaying
3) I had a problem with this version of SS on a linux box and fixed it using this method: http://open.silverstripe.org/attachment/ticket/5547/2.4.0-FileUpload.diff
Tried this in case it was a related problem in IIS, but it didn't fix the issue.
4) looked at file & folder permissions, but IIS doesn't seem to use these. The permissions for all files are set to xxx whether they work or not.
Also, just in case it is pertinent, I have dataobject manager and uploadify installed. Had a problem whereby uploadify/dobjman was failing when trying to manage the Assets upload. However this was resolved. You can see the post at http://silverstripe.org/general-questions/show/15140#post296572#post296572
Hoping someone can help me out with this as I really have no idea where to start debugging it and was supposed to be training the client on CMS today, but had to postpone until I get this fixed.
15 December 2010 at 2:55pm Last edited: 15 December 2010 2:56pm
Hi there LinseyM,
The 500 server error you're getting, is that showing a generic IIS error page?
To get more details when a 500 server error occurs, you can do the following:
1. Open IIS Manager
3. Click Error Pages
4. Click the Edit Feature Settings... link on the right side bar
5. Check the radio button Detailed errors (middle radio button of the three)
6. Click OK and restart IIS
Now server error pages should have more detail in them about the particular error that occurred.
If you find any more details about the error, post them back to this thread so we can diagnose this particular issue.
Hope this helps!
15 December 2010 at 10:08pm
Hi there Sean, thanks for getting back to me so quickly...
I followed those steps, called the URL of the "original image", and it came back with the following:
HTTP Error 500.50 - URL Rewrite Module Error.
The page cannot be displayed because an internal server error has occurred.
Detailed Error Information
Error Code 0x80070005
Requested URL http://www.somedomain.com:80/assets/Uploads/tlogo-alttitude.gif
Physical Path C:\Website\path-name-here\ss24\assets\Uploads\tlogo-alttitude.gif
Logon Method Not yet determined
Logon User Not yet determined
Most likely causes:
* IIS received the request; however, an internal error occurred during the processing of the request. The root cause of this error depends on which module handles the request and what was happening in the worker process when this error occurred.
* IIS was not able to access the web.config file for the Web site or application. This can occur if the NTFS permissions are set incorrectly.
* IIS was not able to process configuration for the Web site or application.
* The authenticated user does not have permission to use this DLL.
* The request is mapped to a managed handler but the .NET Extensibility Feature is not installed.
Also, after reading some of the above, and since I had remote access to the server at that point, I went and had a look at the file permissions in IIS. What I noticed was that files I'd uploaded via FTP or directly on to the server had the group "Everyone" with full permissions set. This included the resampled thumbnail. However, the original file did not have the Everyone group set (just IUSR and a few others), so just out of interest, I added the Everyone Group to the original file and gave full permissions, went back into the CMS, and the file inserted & displayed fine... so it must be something to do with the permission settings in IIS - the thumbnail is generated by the system so I guess thats why it has different properties. But how do I make sure all files that are uploaded have properties that allow them to work? I have emailed their IT team, but not heard back yet. I only know a little about IIS, so I am stumped!
Obviously not looking like an SS issue now, so thats something...
16 December 2010 at 9:17am Last edited: 16 December 2010 10:23am
The assets directory, and all directories and files inside it should have the IUSR user set with read and write permissions. This is the user IIS executes PHP scripts under, and therefore will create any files with this permission as well when you upload/resample. You may wish to double check all the files and folders underneath assets (including assets itself) have read and write permissions for IUSR. I believe if you set these permissions on the assets directory, Windows will automatically apply the permission changes to the child directories and files as well.
However, by the looks of it, that may not be your case... "URL Rewrite Module Error" is interesting, I have not been able to replicate that.
EDIT: I have been able to replicate this issue on an IIS 7.x platform. Looks like a general issue after all. I've filed a ticket here: http://open.silverstripe.org/ticket/6269
1. Create a silverstripe-cache directory inside your project. Give it appropriate IUSR permissions
2. Add this to the top of your mysite/_config.php file:
This should now store temp uploads in the silverstripe-cache directory, and when they get copied to assets, they'll have the correct permissions.
16 December 2010 at 10:59am
hi, thanks for getting back.
I tried the workaround but it still didn't work... (including all the IUSR stuff)
Unless I go onto the server and manually change the uploaded file to permissions Everyone = Full Control, then I cannot insert the file without getting a broken link.
Looks like there might be something else going on in this install with the IIS conifg.
16 December 2010 at 11:08am
You're right, ini_set() doesn't work because PHP doesn't allow you to change the upload_tmp_dir option on the fly like that AFAIK.
The crux of the issue is still the same, when files are uploaded, they sit in the system temp path which inherit limited permissions.
The file is then moved into the assets directory, and therefore missing permissions like IIS_IUSR which stop the rewrite module from being able to check the file to see if it should be rewritten.
The issue is well documented here: http://www.howyoudo.info/index.php/how-to-fix-windows-server-upload-file-inherit-permissions-error/
and here: http://forums.iis.net/p/1166687/1940103.aspx
16 December 2010 at 11:13am Last edited: 16 December 2010 11:14am
Do you have access to C:\Windows\Temp? If so, you could try adding IIS_IUSRS as an additional security item.
Right click C:\Windows\Temp in Windows Explorer and go to Security tab, then add IIS_IUSRS to the list, just as readonly permissions.
I tried this, then uploaded a new file. It now appears correctly. This appears to validate the problem at hand.
16 December 2010 at 11:27am
That fixed it!
Brilliant. thanks for all your help - much appreciated
|Go to Top|