This project is read-only.

Permission denied to delete post on GoDaddy

Topics: ASP.NET 2.0
Dec 25, 2007 at 9:22 PM
Hi, just filed a report to GoDaddy. I'm experiencing the same behavior - access denied when trying to delete a post. Go Daddy recently updated their web interface for setting permissions. Now we must set write permissions via the GD File Manager, used to be via creating a custom directory. Frankly, I don't believe it's the app code either and think it's their new way of applying permissions. Because if I modify the permissions on the App_Data folder to write-only (and remove Read to everyone, deleting a post -does work-, yet editing the post then fails (so it's like one thing or the other, but not both simultaneously).

Strangely enough, sites on GD still running BE.Net 1.2 code keep working fine, including deleting a post of course. I created those sites before GD introduced their new permission interface ...

... which triggers me to try 1.2 code on their new permission system and see if that results in the same 1.3 issues. Post the result in a little while.

Dec 25, 2007 at 9:34 PM
Well, I'm pretty positive I just proved the code works fine. A minute ago, I used the 1.2 version on GD "new permission system/structure" and now I can't delete posts either. Again, BE.Net 1.2 instances created before their new permission interface run smoothly ... and now a newly created instance breaks on deleting a post.

So frankly I can only conclude something at GoDaddy's side broke it. Let's see what GD support replies.
Dec 26, 2007 at 3:03 AM
I have both 1.2 and 1.3 running on GoDaddy, no problem with permissions. But I use directories created before new structure was placed, I just uploaded 1.3 to the existing directory and am able to edit/delete posts...
Dec 26, 2007 at 6:58 AM
Rtur, thanks for your input. Any chance you could create a new test directory and install a new 1.3 instance on the new structure to see what happens? (i.e. not touching your existing directory, we don't want to risk that ;-)

Just got a reply from GD, sighing. I thought they received all the reproduction steps, but they need a complete walkthrough so giving them right now. Let's see what they'll see.
Dec 26, 2007 at 3:03 PM
Just created new test directory, I'll load it this night and let you know what will happen.
Dec 26, 2007 at 8:22 PM
Gee, GoDaddy just replied and basically say unsupported and check your web.config. We all know this is just default BE.Net configuration, so I'm not satisfied with their answer. Here you find more details from GoDaddy response:

...I have found that you have heavily modified your web.config file. I would advise troubleshooting this file to find the error you are receiving. Unfortunately we do not support custom code or scripting for your site.
Dec 27, 2007 at 1:49 AM
Yep, I confirm: new directory, even though looks exactly the same in both "ISS settings" and "File manager" as old one, would not let delete post. If tech support wants to look at it to see what is different let me know. They obviously missed something.
Dec 27, 2007 at 3:10 PM
Whever, I hear you; experiencing the same discussion with GD support. I'm gonna try to write them one more time, politely asking to forget about any application, code or script and just focus on their part: hosting -> servers -> configuration -> file system -> permissions.

I think we all can safely state their new way of setting permissions caused the trouble, right? Keeping you updated ... sighing
Dec 27, 2007 at 6:15 PM
Update from hell, getting in the same loop as whever. Here my abstract of communication with GD support:

My initial response
... Ignore anything about applications or scripts for that matter and please focus on your core support indeed: hosting -> servers -> permissions. Obviously GoDaddy changed to some new IIS administration system. E.g. setting write permissions via the File Manager interface instead of configuring these permissions via Custom Directories.

1. What rights does the ASP.NET system account now has within the changed administration interface?
2. When is this ASP.NET account permitted to perform a “delete file” request?
3. Could you please compare the differences between the file system (and/or share) permissions on these two directories in our account?
a. /test/App_Data
b. /production/App_Data (because here it does work as it should, created via GD previous custom directory interface which included the “write” option)

Again, please disregard anything related to application code/scripts

GoDaddy very dissatisfying reply (within a minute):
As previously mentioned, there are many custom modifications to the web.config file which appear to be part of the issue. We would recommend beginning troubleshooting there.

My immediate response (sent 5 minutes ago) (keeping fingers crossed)
I’d appreciate if you’d answer my hosting related questions. Or forward them to your appropriate department.

Basically all I’m asking when deleting a file is allowed. I’ve checked your IIS settings, Medium Trust Level help and all your other help files. I’ve searched multiple engines and none answers my question. Since you’re the only one able to compare permissions on two different folders in our account, I wouldn’t know who else to ask?

As previously mentioned, ignore any application or scripts, which includes web.config. There’s nothing there that involves file deletion.
And again, that exact same web.config is used for the app hosted in /production/App_Data hence my question only you with physical access to the paths/servers can answer.
Dec 27, 2007 at 10:28 PM
I rather stick to XML too. They came with a response though: "they noticed I configured the custom directory as mypath\engine instead of mypath/engine (using the wrong slash). Well, I just deleted all configuration and created/uploaded everything again just to make sure, but without any change: still unable to delete.

I'll update GD and see what's next.

As curious mind, I experimented with adding this line to the root Web.config:

<identity impersonate="true" />

Everything works as normal than, until I click 'delete' post and then I'm getting a basic auth. prompt. When I fill in my GD credentials, the post disappears! (which actually should be not a very big surprise, because we already concurred ASP.NET simply has some limitation or conflicting NTFS permission to delete. Still, this could be a very, very dirty workaround to make all functionality complete ... of course, GD simply has to revise their permission config - so let's focus on that.
Dec 27, 2007 at 10:51 PM
Since we're all (trying to) communicate with GD support, I figure to keep you wonderful guys in the loop as well. Just informed GD:

... Unfortunately using the proper forward slash still prevents deleting a file. To be on the safe side, I completely deleted the existing custom directories and content and recreated it according to your guidelines.

/engine/App_Data still doesn’t allow the ASP.Net account/process to delete a file, so would you please dig further?

Frankly, the only thing I can come up with is too limited permissions set for Network Service on your IIS 6. My guess is that using the GoDaddy File Manager and setting a folder on Read plus Write, the Network Service (ASP.NET) conflicts or is not granted delete permissions.

Many thanks,
Dec 28, 2007 at 12:13 AM
With that being said, and I don't know the full scope here...

<identity impersonate="true" userName="contoso\Jane" password="pass"/>
Dec 28, 2007 at 11:28 AM
Edited Dec 28, 2007 at 11:32 AM
Earlier I thought setting the App_Data folder to write-only (and remove web-visible) would enable post deletion. I just found out this is not really the case: although no error is thrown and the post in fact disappears from the website, the actual .xml post still exists in /app{{_}data/posts. So if the application restarts (e.g. modifying web.config or reuploading the .dll), the 'deleted' post shows again - so nothing really deleted.

Frankly, I'm losing hope to get a satisfying GD answer, so perhaps I'll keep using the <identity impersonate="true" /> addition.
(ckincincy, thanks for the extra options - still I rather not store those credentials in plain text).

Anyway, I appear to be in the GD loop again, cause now they're asking me the same ol' questions. Sighing, why don't they just compare the two custom directories and see the permission differences for the ASP.Net account they use (assuming they don't use Network Service on a shared hosting environment).
Dec 28, 2007 at 1:47 PM
Using the impersonate feature, the loginbox prompts only if <customErrors mode="Off">, if switched On or RemoteOnly, the delete attempt will redirect to the defaultRedirect error. Deep sigh ... why oh why did GD have the urge to change a once working permission structure!?
Dec 28, 2007 at 4:20 PM
Just hang up on a friendly GD Hosting engineer. She confirmed with the new IIS Settings mode, they restricted the ASP.Net rights to read/write/modify but no delete. After our phone conversation, I received the following by email too:

It appears that your blog application is attempting to delete a file from a virtual directory through the anonymous user account. Unfortunately, you will not be able to set up anonymous directory modification rights with our IIS permissions tool. Per our conversation, we recommended that you use a database for blog entries and deletions or check out our blogging applications offered in the GoDaddy Hosting Connection site.

Guess a mySQL DB it is ...
Dec 28, 2007 at 6:28 PM

Drop them, and specify this when you do. It is the only way they will learn.
Dec 28, 2007 at 9:03 PM
You're welcome Whever and I wish you'd get some better news from the front. Personally I'm still doubtful to move a DB, since the XML store is so light-weight, and portable. Perhaps I'll just accept the fact I cannot delete a post and simply uncheck 'publish' if I want to prevent it shown (and reuse for a new post ;-)

My idea was to create a sort of BE.Net ModPack (for Medium Trust environments like GD). It's 95% finished, but the whole no-delete rights throw off my plan or at least my schedule. There's one other workaround I found, but unfortunately not very consistent (sometimes it works, sometimes it doesn't):

I created a plain subfolder e.g. "/auth/" (so nothing like a GD custom IIS directory) and removed the "Web Visible/Read" option. Whenever you browse to that directory, it prompts for a basic authentication (only Windows account working is the same FTP credentials for GoDaddy). For some reason, sometimes after authenticating all of a sudden the 'delete' actually works, assuming it's my added <identity impersonate="true">, but again - other times it triggers the defaultRedirect in the custom errors section. Can't explain the inconsistency :(
Dec 29, 2007 at 5:02 AM

Using GoDaddy and SQL Server Database here with no problems. It's a no brainer to setup - just run the script and follow some specifics (like be sure to remove '<trust level="High" />' from the web.config...) found here at this forum -
Dec 29, 2007 at 7:10 AM
I've been having the same issues like all of you here with GoDaddy. Besides that though, I am also having an issue running the sql code to set up all the tables. I simply copy and paste the set up sql code into the query analyzer to run it, but it errors out on line 8:
-> Line 8: Incorrect syntax near '('. Can anybody help?

Dec 29, 2007 at 11:40 AM
Edited Dec 29, 2007 at 12:28 PM
Whever, would be great if you find out more with GD on the phone. I completely concur with you: why the heck change a working system.

Glad you like the idea of this modpack and I'll publish about it soon. The word "mod" is twofold 1) modified 2) moduled. The latter explains itself, simply with added extensions (like the MP3- and Flash players). Modified, because I revised the source code to run BE.Net as "simulated root" (/) instead of (~/). You'd find out that running BE.Net in custom directories, the blog URLs resolve to your GD application path (e.g. /whever111-com/blog).

The precompiled ModPack contains all those changes and additions in one .zip file. All you need is to upload that single file and use GD File Manager to unarchive it in your desired application folder (and with their new IIS Setting/Permission structure, the only good thing is that App_Data can be a non-custom directory now). I must admit, this upload/unarchive method works much better/faster IMHO than uploading every individual files (which takes ages). Not so big deal if you only need to upload 1 BE.Net instance once, but regularly updating or testing new builds like that, well ... major speed improvement.

Also interested in the answer to your SQL question, I run quite some BE instances and just like you have "just" 2 SQL DBs (wonder if mySQL works well and easy on BE.Net too. We got 25 of those and GD tied the maximum size to our allotted disk space (1GB :)

Thanks again and I'm very grateful we're all in this together. The more GD customers pressure, the more likely they'll act :-)

(BTW: GD will call you no matter your location, like South Africa. They called me too on my Dutch cell phone)
Dec 29, 2007 at 5:22 PM
whever111, I am running BE 1.3. I simply opened the setup folder, which contains the readme.txt and MSSQLSetup1.3.0.0.sql files. I copied the sql file code over into the Query Analyzer in GoDaddy and then get the error when trying to execute it. I've tried it several times now, making sure I copy the entire code, broke the code out to see if there was a comma or a parathesis missing, but I can't see anything wrong with the code. Any ideas?
Jan 3, 2008 at 6:04 AM

Starlight wrote:
whever111, I am running BE 1.3. I simply opened the setup folder, which contains the readme.txt and MSSQLSetup1.3.0.0.sql files. I copied the sql file code over into the Query Analyzer in GoDaddy and then get the error when trying to execute it. I've tried it several times now, making sure I copy the entire code, broke the code out to see if there was a comma or a parathesis missing, but I can't see anything wrong with the code. Any ideas?

Hi Starlight,

I'm pretty sure your issue is SQL Server 2000. The script is written for SQL Server 2005. Since you mentioned Query Analyzer, I'm guessing you are connecting to a SQL 2000 db. The script would need some modifications to get it to work with 2000, but BlogEngine would have no SQL 2000 issues beyond the install script.
Jan 3, 2008 at 8:35 PM
Thanks you guys! And, as it turns out, you were right, it's still running a SQL Server 2000 database ... I've sent them an email to see if it's possible to upgrade.

Jan 6, 2008 at 6:35 AM

Well, I've run into the same post deletion problem as you guys with godaddy...but I do have a work around.

I had initially run through the automated BlogEngine install, which configures v1.2 and creates a SQL Server database for you. This worked fine. I then saw that v1.3 of BE was out so I wanted to install that to try it out. I manually created an app root and installed it with a default XML provider. Things worked fine except for the delete post, as mentioned above. I then went over to the auto-created BE install and switched it to XML - and deletions worked.

I have since verified that running through the auto-installer and then just switching things over manually works - the XML posts are removed from the App_Data/posts folder. Here's a quick rundown on what I did:

1) Log into Hosting Control Center
2) Under Content, go to Go Daddy Hosting Connection
3) Select Blogs-->BE v.12
4) Run through the wizard (database info, location, admin name)
5) The installer will take 5-10 minutes to get everything setup
6) Now you can either:
---- A) Edit the web.config to use the XML provider, or
---- B) Copy over all your real BE files or v1.3 files (I did the latter)
7) Be sure to go back in and delete the database that was created

I've tried this three times and it has worked. Just to mention though, if you mess with the permissions on the blog root folder or the App_Data folder with GD File Manager - IT WILL BREAK.

Hope that helps.
Jan 6, 2008 at 9:52 PM
Excellent workaround, definitely worth the try! Whever, let's hope GD comes up with a fair answer - my philosophy would be "Thy who'd break, should fix" ;-)
Jan 11, 2008 at 2:41 AM
Hi guys,
I just tuned-in to your discussion after searching google for anything aboug GoDaddy file deletions. I am having a similar issue - I have a content management tool that I've had working for months, where users can upload images for different event photo albums. Just a short while ago, w GD's new interface, my 2.0 code no longer allows for my users to delete images!!! Absurd! I've wasted hours checking code, directory permissions, rebuilding the directories and resetting permissions, numerous GD phone calls - only to ultimately be told that I need to just let the files remain on the server (how smart is that?) - or - recode all my pages to accomplish the delete using ftp credentials. I am FIT TO BE TIED!!!

I'm starting to search for an ftp procedure to do this as I've never had to do this before. I used to host with Host Excellence but switched 'cuz they weren't going to .NET 2.0 any time soon - I MISS THEM! At least they knew what they were doing for the most part.

Anyway - anyone have any good ftp code?

~ Sue
Jan 11, 2008 at 4:59 AM
Go post a comment on Bob Parsons blog complaining about this.. get his attention and we may get it fixed.
Jan 14, 2008 at 10:32 AM
YES! GREAT! It -is- fixed! Just tried it in an account that failed deletion first. Had to reapply permissions via the File Manager, but after this simple, easy step - deleting posts works.

Going to test different scenarios the next hours to see if that keeps working too. So later today, I can 'officially release' the ModPack for BlogEngine.NET (specially for Windows Shared Hosting, like GoDaddy). Oh my, excellent news Whever - thank you so much!
Jan 18, 2008 at 1:14 AM
Edited Mar 10, 2008 at 3:28 PM
Hi Whever, sorry it took longer than I expected, but it's finally here ;-)

You can read the complete guide to ModPack here.
The download is available on a dedicated CodePlex project site (since I can't add files on BE's project).

Looking forward to your feedback!
Mar 28, 2008 at 11:47 PM
This issue has been resolved? I would like to use an blog with godaddy, but I am not an programmer by any means, still teaching myself basic stuff. Seems to be resolved - and if so - it ended up being with Godaddy? Is Godaddy reliable given all the hassle with just being able use open source blogs? Seems like the hassle may be driven in that they want to use their version of blogengine so they can put their ads on it or their blogcast that you pay for.
Oct 7, 2008 at 4:43 PM
I understand that the last post in this thread says that the issue has been resolved. However, I am receiving the error right now and getting the same standard replies from GoDaddy. Any advice as far as seeing this resolved in my account?
Oct 9, 2008 at 9:37 AM
@Samwise, so you've set write permissions on App_Data via GoDaddy's file manager?

GoDaddy's change/fix which resolved our issues, should work across all their accounts.
Can you provide more details about your taken steps and error messages?