Error messages when using BE in a sub-directory - URGENT

Dec 8, 2008 at 11:23 PM
I am using BlogEngine 1.4.5 in a sub-directory like http://www.example.com/blog and everything seems to be working ok except for one thing. When using the admin tabs like BlogRoll, Controls, Categories, Settings, etc, I am getting error messages when I try to save any changes I make. The funny thing is that, despite the error messages, in some cases the changes do get saved. Sometimes they don't though. One complete exception is the Add Entry tab. I don't get any error messages on this page and posts are saved without a problem.

I have followed all of the installation instructions in Al Nyveldt's video ( http://www.nyveldt.com/blog/post/BlogEngineNET-14-Installation-Screencast.aspx ). I am thinking the problem could be because the "blogs" directory is set as an application inside of an application and it's confusing BlogEngine.Net or ASP.NET. Possibly ASP.NET is sometimes looking at the higher level APP_DATA folder instead of the one in blogs.

Does anyone know how I can get around this? I have a requirement to get a blog launched very quickly and really like BlogEngine.NET except for this one problem.  

Oh and the error messages are pretty much all the same and look like this:

Access to the path 'D:\....\.....\blogs\App_Data\blogroll.xml' is denied.
Description: An unhandled exception occurred during the execution of the current web request. Please review the stack trace for more information about the error and where it originated in the code.

Exception Details: System.UnauthorizedAccessException: Access to the path 'D:\...\....\blogs\App_Data\blogroll.xml' is denied.

ASP.NET is not authorized to access the requested resource. Consider granting access rights to the resource to the ASP.NET request identity. ASP.NET has a base process identity (typically {MACHINE}\ASPNET on IIS 5 or Network Service on IIS 6) that is used if the application is not impersonating. If the application is impersonating via <identity impersonate="true"/>, the identity will be the anonymous user (typically IUSR_MACHINENAME) or the authenticated request user.

To grant ASP.NET access to a file, right-click the file in Explorer, choose "Properties" and select the Security tab. Click "Add" to add the appropriate user or group. Highlight the ASP.NET account, and check the boxes for the desired access.
Coordinator
Dec 8, 2008 at 11:34 PM
It sounds like you need to setup write permissions for the App_Data folder.

http://razorant.com/blogenginewiki/Installation.ashx#Add_write_permissions_for_App_Data_folder_3
Dec 8, 2008 at 11:39 PM
That is not the problem. I have definitely set write permissions for the App_Data folder and quadruple checked it. Anyone else have any ideas?
Dec 9, 2008 at 12:01 AM
It is certainly related to permissions not being set.

Do this on the server:
http://www.ocdprogrammer.com/post/2008/08/10/Failed-to-access-IIS-metabase.aspx

Then redo your permissions on that directory, not through IIS but through Windows explorer.


Dec 9, 2008 at 12:15 AM
Thanks for your reply. I can't reinstall .NET like that without the permission of the server admin and I don't believe .NET was installed before IIS on this server.

As for doing the permissions through Windows Explorer, that I  have done and redone about 10 times. One weird thing though, I can't get the Read-Only attributes unchecked. See this screenshot: http://zaptank.com/images/temp/readonly.gif
I do uncheck it, hit apply, it appears to go away and then comes back. I thought this didn't matter, because I've seen this for a while on Windows.

Lastly, I still think the problem could be a result of having one application inside of another.
Coordinator
Dec 9, 2008 at 12:20 AM
Edited Dec 9, 2008 at 12:25 AM
Getting read-only turned off is probably the first priority.  If some files or folders are still read-only, that's practically the same as not having write permissions.  Maybe try clicking the 'Advanced' button and see what's there, or Google to find out why you can't turn read-only off.

EDIT:  On my development machine (Vista), I also see Read-Only as only partially checked and can't keep it fully unchecked ... but I'm not getting any errors like you're seeing.
Coordinator
Dec 9, 2008 at 12:32 AM
By the way, which account are you giving permissions to the App_Data folder for?  This link may be relevant,

http://www.vamsee-konda.com/post/2008/04/BlogEnginenet-error---Access-to-the-path-blogrollxml-is-denied.aspx

That other link I posted before too discusses the account you may need to give write permissions to.
Dec 19, 2008 at 4:46 PM
This problem was solved when I moved the website to the production server. No problem writing to App Data there. I did everything correct on the development server, but it must have been something on there that was different. I didn't have to, but I also switched to using SQL server as the data store, so I think I am only using the App Data to for user.xml now.

The only weird thing now is making edits to the Profiles (Profiles tab) does not seem to work. I  hit "Save Profile" but it does not save. It keeps the same profile info for all users   Anyone ever run into problems with that? 
Coordinator
Dec 19, 2008 at 5:38 PM
There's some quirkiness with editing/saving/selecting Profiles -- especially if you have more than one user.  Some time ago, I uploaded a patch (patch ID 2091) that fixes a number of issues on the Profiles tab.  I don't think any of the code I submitted in this patch has been integrated into BlogEngine.

IIRC, profile changes should get saved though.  If you select a user from the dropdown box, click "Switch to User Profile", make changes, save changes, navigate to a different page, return to the Profiles tab, select the user you made changes to, click "Switch to User Profile", do you see the changes you just made?
Dec 19, 2008 at 6:02 PM
A profile change gets saved, but the problem is the same information is saved for every user. If change user 1 to first name Thomas, then all other users get the first name Thomas. It's like that with every field.
Coordinator
Dec 19, 2008 at 6:26 PM
It just appears that the same changes are being saved to every user.  You can verify what Profiles exist and what values exist for each Profile by looking in the be_Profiles SQL table.

The problem is that if you Switch to a different user and there is no profile for that user, the fields on the screen are not cleared out and whatever field values were there just remain.  This makes it appear that the settings for the user you just selected are the same as the last user's settings you were just looking at.  When in reality, there is no profile for the person you just selected.

Another related problem is that when you first get to the Profiles tab, the settings you see are not necessarily for the user you see selected in the dropdown box at the top.  IIRC, the first user in the dropdown box is selected when you get to the page, but the settings in the fields below are for you (or whoever you are logged in as).

Like I mentioned, this page is full of UI problems.  I hope one of the developers can integrate the code in that patch I uploaded into BlogEngine.
Dec 20, 2008 at 6:06 PM
Wow the profiles admin page is pretty messed up, but what you mentioned helped me make some sense out of it and do what I need to do, thanks :)  To set different profile information for each user you have to log in as each user. Trying to set or view profile information through an administrator login and using switch to user profile is very problematic or not working at all. 
Coordinator
Dec 20, 2008 at 6:11 PM
You're not the first person to be confused :-)  If you want, you could download that patch I uploaded.  There's 3 files in it.  Two of them are profiles.aspx and profiles.aspx.cs.  You could replace your current versions of these files under Admin\Pages with these 2 files.  This should pretty much fix all the confusion.  The third file, labels.resx, just has a spelling correction ... not such a big thing.
Coordinator
Dec 26, 2008 at 5:58 PM
These problems on the profiles admin page should now be resolved.  Patch 2091 which included the necessary fixes was applied in changeset 23719.
Dec 29, 2008 at 10:24 PM
Thanks for creating that patch. Just applied it and it works like a charm.
Oct 14, 2009 at 6:28 PM
ckincincy wrote:
It is certainly related to permissions not being set.

Do this on the server:
http://www.ocdprogrammer.com/post/2008/08/10/Failed-to-access-IIS-metabase.aspx

Then redo your permissions on that directory, not through IIS but through Windows explorer.


 The command at this link fixed my "Failed-to-access-IIS-metabase.aspx" message.

Thanks!