From my own recent experience, some GoDaddy accounts definitely do not have permissions to update the Web.config file in the root, causing installation to crash.

Fortunately, the steps to get around this are pretty easy, just manually upload the backup files from the Config directory.

Note -- before running installation make sure you set permissions on the Config directory, as that is where the backup files are written.

After getting the error: (solution tested on DNN 4.0.2)

 1. Download (via FTP) the new web_.config file from the backup directory. (Note the underscore, also note you do not need the web_old.config, which is a backup of the original config.)

 2. Replace your previous web.config, in the root, with the web_.config file from the backup (Note the underscore needs to be removed).

 3. Also copy SiteUrls.config from the Config directory into the root.

 4. FTP up both the new web.config and SiteUrls.config.

 5. Restart the install, and it should continue.


Technical Notes:

I recently created a new shared hosting plan on GoDaddy and tried installing a new instance of DNN 4.0.2. I had no problems ensuring my database connection was correct, or adding the permissions for the Config directory. But, like smartd & others, I did hit the permission problems writing to Web.config and SiteUrls.config.

I'm not sure if it is only newer GoDaddy accounts that are having problems, or if it is some other difference, but the solution above should get around the problem for anyone who encounters it.

Having a background in .NET development, it was relatively easy to work out the problem looking at the Install.aspx.vb code.

The installation for DNN is a two-part process. On the first pass it updates the Web.config and SiteUrls.config files, then it reloads the same page to continue the rest of the setup.

The reason it writes a new Web.config is to update the machine key for membership with a random value; I don't know why it changes the SiteUrls.config file, but possibly to cater for upgrade scenarios.

Doing a diff on the config files before & after the only two changes appear to be the <machinekey> (as above), and also adding a setting, "InstallationDate", to the appSettings. (There is also a lot of whitespace differences and reformatting.)

It is the presence of this setting, the "InstallationDate", which causes the second part of the installation to continue.

This means, if you copy a config file from a local test installation, from someone else, or are doing an upgrade, it will work because it has the "InstallationDate" set. (However, it means you will get the same machinekey as them.)

Even if the install process does not have access to the root directory, provided it can write to the Config directory, it will first write the changes to Web_.config in the backup directory, so it is relatively easy to manally complete the copying process to FTP these files into the root directory and continue.

As a side note, part of the install process for modules cleans up by deleting the ZIP file, however without permissions on the Install directory this can't be done either. This means you may end up with a bunch of ZIP files left in these directories (I think this is mostly harmless, but you may want to clean the up just in case.)

I followed Michael's instructions (for install to GoDaddy) and the more recently posted guidelines carefully over the weekend.  I was able to install and run at my site root level, but when the site comes up, all the content is blank.  There are no error messages being returned so the install is happy, but apparently no modules were loaded.  I think it must be a permissions problem which has consumed a lot of talk time in the forum.  Does anyone have any ideas on how to fix?  I don;t know enough about the DNN architecture yet to know which folder may be the problem.  I did however check the remote site versus my local machine (upon which the site runs just fine) and it appears that all files were copied successfully to the remote site.  Nothing appears to be missing.

Thanks in advance,

Joe

George,

You should have the "default" folder in the "Portals" folder before the install.  Many of the files for the "0" folder (initial portal) are copied from the default folder.  Without this folder your portal will not be able to install the files and installation will fail.  This seems to be a common problem of late, files and folders are not being properly copied to the root through ftp.  Try re-uploading the web content.  Then compare all the folders on the root with the extracted folders on your computer that you uploaded.  Upload any that are missing. 

For reference, what is the FTP client that you are using?