Godaddy WIMP Wordpress Web.Config Error To LAMP Parent Directory Writeable?

Normally this screenshot would be posted over in Errorprocessing.com, but since this error wasted many hours, I'm posting it here.

This is how it started -- seemingly just an ASP.NET or hosting configuration issue.

Godaddy Windows Shared Hosting: Error Thrown after Wordpress Install

Configuration

IIS7.ASP.NET 4.0/4.5, MySQL (Win), PHP 5, root D:\Hosting\7207009\html

There have been eight back and forth emails and three phone calls so far with Godaddy support. As has been noted elsewhere, Godaddy support is more conversant with Linux Wordpress than with their IIS - Windows platform, though this is not reflected in anything official.

A significant benefit with Godaddy (and other web host firms) is that they perform the function of installing the application through the use of wizards. When it works -- and most of the time it does work, even in Windows -- it's a timesaver. I'm conversant with self-installing, and am a former virtual host customer of Godaddy's, but found that one inherits unwanted system administration duties along with the benefits of having root access.

This error appeared after the Godaddy wizard that installs Wordpress on Windows, which has this menu tree:

Account | Web hosting | Hosting Account selection (by domain) | Applications | Wordpress | Install

The subject hosting account already had two successful Windows installations of Wordpress. One of these

Godaddy "Wordpress Is Ready" Email

continues to work OK (launching after a painful wait of 20 seconds before the home page displays, but that's a different issue), as did the previous installation.

There is no visible web.config file, either via ftp or the file browser provided in Godaddy's hosting control panel, though obviously one (or something that is a proxy for one?) is in play based on the error being thrown. That includes both the root of the hosting site (\) or the subfolder where Wordpress was installed (\foo).

To sum up the current status, the wizard installs an inaccessible version of Wordpress that cannot be browsed from the post-installation link given by the notification email sent by Godaddy.

Tips on the web? Most deal with fixing Windows permalinks on Wordpress, which is an issue one encounters after the administrative interface is breathing.

What Was Tried? 

1. Uninstalling an install at the root
2. Reinstalling at a subfolder (but tested at the root (see #10).
3. Putting a dummy web.config at the root 
4. Installing the rewrite-enabled web.config recommended at Amixa.com. 
5. A test testphp.php file to verify php configuration setup on this virtual site. It failed with "No input file specified". This typically means IIS and PHP aren't collaborating, but in fact PHP runs on the operational site, so this error was misleading.
6. Changed php.ini so that doc_root pointed to the physical root of this site. No change.
7. Reviewed "Enabling per-site PHP settings."
8. Checked IIS Management, and the virtual server site had not been set up. One was created. The application pool was manually recycled. No effect (but see #10).
9. A CSR suggested enabling error display (as suggested here, errormode = "Detailed"). This had no effect. It was as though a local web.config was not being accessed.
10. When verifying that HTML could be read on the site, this also failed. This suggested a DNS setup problem. That was a key insight for this phase of the solution.
11. The primary domain was changed to an idle domain name. This created a new Wordpress instance that was one of two secondary domains on the hosting account.
12. Permissions on the entire Wordpress folder were changed to read/write.
13. The application pool for the hosting account was recycled.

Status After Round 1 of Remediation Attempts

At this stage, the "primary domain" was abc.com, but the Wordpress instance of interest was in a subfolder. Despite using the wizard, and probably for good reason, the domain continued to point to the root even after the Wordpress install and re-install. Accordingly. the site must be accessed at:

http://abc.com/subfolder/wp-admin

OK. The original web.config issue remained unsolved when Wordpress was installed to the root, but this issue is masked when Wordpress is moved to a subdirectory. This was probably working after the reinstallation of the Wordpress instance, but I erroneously tested it from the subfolder URL.

That change resolved the web.config issue for the secondary domain. As noted. the primary domain throws the web.config error, but that's tolerable.

But . . .

Now it was not possible to upload any images to the wp-content\uploads folder. See below.

Wordpress Upload Permissions Error (Windows - IIS - MySQL - PHP)

Error message:

has failed to upload due to an error. Unable to create directory abc.com/uploads/2013/07. Is its parent directory writable by the server?

The browser uploader likewise failed with the same message.

Did ftp work? No problem to ftp to the folder, but that was no help. It showed that ftp had write permissions, but does not allow Wordpress the chance to index and otherwise manipulate the images as needed to stick them in a post.

I unsuccessfully implored the Godaddy CSR to have "Advanced Hosting" look at the event logs, which might be tedious as the error is diagnostic rather than serious, but that could help determine the cause of the permissions error. (In retrospect, it is unclear whether this would have helped much.)

There are also other solutions (see References below) that were tried with some success by other Windows Wordpress users (unclear how many of these were on hosted accounts), but since the conversation was had with a Tier 1 rep who was relaying information to the Advanced Hosting resource, I did not try to suggest them.

Second Strategy and Results

The primary domain was changed to an idle name, then reinstalled a second time at the subfolder. This left the primary domain with the original web.config error.

Unfortunately, media uploads are now not possible, even though there is another secondary domain running Wordpress in a parallel folder on this hosting account whose uploads work fine.

After seven overall tickets with Godaddy support, their last recommendation was to "Contact Wordpress" or move the hosting to Linux instead of Windows.

Move to Linux and Resolution 

The move to Linux from Windows was requested of Godaddy's hosting ops on a Friday and completed on the following Tuesday. There were some unexpected twists.

• There were three domains associated with the hosting account; one of these was the pesky one described in this blog post. The other two domains were working OK under Windows, but Godaddy only restored two domains to working order.
• The Wordpress instance with the problem was erroneously attached to the wrong subfolder, which made testing a big confusing until I noticed the mistake.
• Here's the big twist. Once the folder issue was identified, the identical problem recurred -- the exact error message ending with the nagging query ". . . Is its parent directory writable by the server?"

Following this odd finding -- that the presumed Windows problem moved intact to Linux -- permissions on the folder tree were reset (step 12 above), this time under Linux. The result was the same. It had no effect.

Clearly it was time to return to Google Search for more findings (i.e., other user frustrations), since this now seemed to be a Wordpress, rather than an operating system-depending issue. Eventually what turned up is what I'm calling the "Morigirth Fix" (see below). It involved toggling a boolean in Wordpress Media Settings.

Most Wordpress media settings screens look like this, shown at Wordpress.org.

Wordpress Media Settings Screen: Default Settings

Note the boolean:

"Organize my uploads into month- and year-based folders." 

To "fix" the permissions error, this was unchecked, and the problem was resolved.

Wordpress seems to want to reset this flag to "on," because the next day it was reset to true. Uploads are working fine.

Analysis 

This was a Wordpress issue whose solution should be suggested as part of the error thrown. In addition, the web host is likely to have seen this before, but hasn't created a knowledge base record for it. I am unclear as to the original cause for the problem, but it is clearly in the Wordpress - php interaction with the file system.

Suggestions by Others 

This section of the post is for reader use. None of these suggestions worked directly -- this time -- but may be useful for others with similar symptoms.

• Tweaks to web.config Tip shows use of Microsoft Platform installer (using IIS), not applicable here, but the author provides a glimpse of the web.config tweaks made for rewrite rules. In the example shown, web.config is placed in the subfolder.
• Failure to Detect IIS 8 There's a failure to detect IIS 8 in a Wordpress php file, but the suggestion had no effect on this issue.
• Review IIS Authentication This post suggests changing the IIS7 authentication. According to them, “Anonymous Authentication” was set to a user that did not exist. So they changed it to use the application pool identity. It is unclear to me whether the Godaddy data center (1) has that option given their shared hosting setup, and (2) tried it when it was suggested.
• Review temp directory settings This post suggested changing permissions on the PHP temp directory, but since a different instance on the same hosting account worked, it was not attempted. A variation on this was also suggested: give the ‘IUSR’ account modify permissions on the WindowsTemp directory and restart IIS. This idea was similarly phrased by another user as "Changing permissions on windows/temp so that IIS_USR could access it." That was not tried, either, as access to this folder is not permitted on shared hosting accounts.
• The "Morigirth Fix" This is the Wordpress setting that resolved the permissions problem presented in this post.
• Set Media Loads to Use One Folder This forum post suggests that it is possible to unstick the boolean.