RadChart v 2012.1.215.35 Write Permission Errors to TempImagesFolder

Thread is closed for posting
3 posts, 0 answers
  1. Mich Meow
    Mich Meow avatar
    6 posts
    Member since:
    Jan 2010

    Posted 04 Feb 2013 Link to this post

    Dear Telerik,

    I'm using RadChart v2012.1.215.35 in an ASP.NET 3.5 application hosted on Win Server 2008 R2 / IIS 7.5 and I am getting a write permission error to the temporary images folder despite all users having full control access to the folder. The application is using the ASP.NET State Service for storing session state which was causing RadChart to throw a serialization error when using out of proc session state. Checking the forums for resolution I have changed Rad Chart to use a temporary folder for storing the chart images instead of session.

    <telerik:RadChart ID="rcNAVHistory" SkinsOverrideStyles="true" runat="server" Skin="Vista"
        Width="880px" Height="400px" AutoLayout="true" IntelligentLabelsEnabled="true" UseSession="false" TempImagesFolder="~/Temp">
        <ChartTitle>
            <TextBlock Text="NAV Per Security and USD Totals" />
        </ChartTitle>
        <Appearance TextQuality="AntiAlias">
        </Appearance>
    </telerik:RadChart>

    The security on the Temp folder is setup with the app pool service account, ASPNET user, NETWORK SERVICE, and Everyone with Full Control to the directory but the application is throwing the following error:

    A generic error occurred in GDI+. Check the folder specified in the TempImagesFolder property of the control. Current value is "/App/Temp". The folder should exist and must have been granted write permissions for the ASPNET user. *** Source *** Telerik.Web.UI *** Target Site *** Void RenderClassic(System.Web.UI.HtmlTextWriter) *** Stack Trace *** at Telerik.Web.UI.RadChart.RenderClassic(HtmlTextWriter writer) at Telerik.Web.UI.RadChart.RenderContents(HtmlTextWriter writer) at System.Web.UI.WebControls.WebControl.Render(HtmlTextWriter writer) at Telerik.Web.UI.RadDataBoundControl.Render(HtmlTextWriter writer) at System.Web.UI.Control.RenderChildrenInternal(HtmlTextWriter writer, ICollection children) at System.Web.UI.Control.RenderChildrenInternal(HtmlTextWriter writer, ICollection children) at System.Web.UI.HtmlControls.HtmlContainerControl.Render(HtmlTextWriter writer) at System.Web.UI.Control.RenderChildrenInternal(HtmlTextWriter writer, ICollection children) at System.Web.UI.HtmlControls.HtmlForm.RenderChildren(HtmlTextWriter writer) at System.Web.UI.HtmlControls.HtmlForm.Render(HtmlTextWriter output) at System.Web.UI.HtmlControls.HtmlForm.RenderControl(HtmlTextWriter writer) at System.Web.UI.Control.RenderChildrenInternal(HtmlTextWriter writer, ICollection children) at System.Web.UI.Control.RenderChildrenInternal(HtmlTextWriter writer, ICollection children) at System.Web.UI.Page.Render(HtmlTextWriter writer) at System.Web.UI.Page.ProcessRequestMain(Boolean includeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint)

    Any advice would be appreciated. 

    Thanks,
    Andrew.

  2. Petar Kirov
    Admin
    Petar Kirov avatar
    425 posts

    Posted 07 Feb 2013 Link to this post

    Hi Andrew,

    Generally you should not have any problems with the Temp folder set up like that and it is really strange that you are facing such problems with the ASP.NET account as this is the account that would write the image (unless some kind of impersonation is in place in your application). 
    To track-down the problem, you can test if you can save an arbitrary file to the same folder in code from your application.
     
    Regards,
    Petar Kirov
    the Telerik team
    If you want to get updates on new releases, tips and tricks and sneak peeks at our product labs directly from the developers working on the RadControls for ASP.NET AJAX, subscribe to their blog feed now.
  3. UI for ASP.NET Ajax is Ready for VS 2017
  4. Mich Meow
    Mich Meow avatar
    6 posts
    Member since:
    Jan 2010

    Posted 07 Feb 2013 Link to this post

    Hi Petar,

    You can close this issue. Doing an IIS Reset has cleared the condition from happening. It seems like IIS has cached permissions to the folder and the IIS reset caused it to pickup the updated ACL to the folder location. (My best guess on this one)

    Cheers,
    Andrew.
Back to Top