DotNetNuke file create failing

jpetley

Guppy
Argh another DotNetNuke thread...

I have two installations of DotNetNuke, my first installation is perfect, no problems at all.

The second on the other hand runs great, up until i want to install custom skins of modules, when i get file creation failures.

I have deleted DotNetNuke and reinstalled, reset and had all the permissions double checked (file permissions and db permissions) but still the file creation part of module install fails.

If anyone has anything to add that may help i would be very much obliged.

Cut and paste below :

StartJob Creating files
Failure Exception: System.IO.DirectoryNotFoundException: Could not find a part of the path "D:\". at System.IO.__Error.WinIOError(Int32 errorCode, String str) at System.IO.Directory.InternalCreateDirectory(String fullPath, String path) at System.IO.Directory.CreateDirectory(String path) at DotNetNuke.Installer.PaDnnInstallerBase.CreateModuleFile(PaFile File, PaFolder Folder) at DotNetNuke.Installer.PaDnnInstallerBase.CreateFiles(PaFolder Folder) at DotNetNuke.Installer.PaDnnInstallerBase.Install(PaFolderCollection folders) at DotNetNuke.Installer.PaInstaller.Install()
 
The servers do have D, as that is where we have user files by defualt,but it should contain the whole path to your user directory, as your user does not have access to the D:\ folder, only your user level folder.
 
As a default install, why would it be asking for D: ?

I havnt actually changed any of the paths, at this stage i have only edited the web.config file to point to my sql database.

I will try the 3.0 version of dotnetnuke and see how it goes.

Thanks for your answers,

Jason
 
try changing your web.config to use

<identity impersonate="false"/>

make sure you move it out of the comment section from the default DNN distribution
 
i tried setting the impersonate attribute, but web.config won't load (i get a runtime error trying to set to false). not sure what is causing this, but should not make a difference. impersonation is false by default anyways.

i had to modify the dnn source code just to install dnn 3. basically, replaced calls to Directory.CreateDirectory with the FSO object method CreateFolder.

still having issues with installing a custom module. it makes a call to Directory.SetCurrentDirectory which also fails due to below issue.

have not received a good answer to the below request. granting READ ATTRIBUTE to the process running my website would resolve this issue i believe.


here is what i sent to jodohost after i researched:


has anyone been able to successfully install dnn 3?

i get the following error during install:

Could not find a part of the path "D:\".

i got the following from the dnn forum:

Q. What permissions are required for DNN to function properly under W2K?

A. The ASPNET account (which is the account used for running the asp.net worker process) must have FULL permissions on the WEBROOT and all subfolders for the DNN application. There are several conditions where the application writes files both to the root (e.g. child portal folders) as well as to subfolders (e.g. uploading portal files).

** Important note ** Under W2K only, the ASPNET process must also have READ ATTRIBUTE privileges (not read file) on the DRIVE ROOT (e.g. D:\) for the DirectoryInfo class in .NET to work correctly.

>>> If you're on W2K, make sure your administrator understands your asking for READ ATTRIBUTE privileges... not read file (which would be a security issue). "

here is a link to this for more info:

http://www.asp.net/Forums/ShowPost.aspx?tabindex=1&PostID=864657

my question is:

can the aspnet process have READ ATTRIBUTE privileges on d:\?

if not, is there a known workaround for jodohost?

thanks, rick..
 
it already has the read attribute

In fact I just logged in and it has both:
Read Attribute and Read Extended Attribute
 
will you verify for me that the following account has READ ATTRIBUTE rights on d:\ and has full control of my webroot and sub dirs:

roa71

this is the account i am running under.

thanks, rick..
 
we have many other DNN installs that have never needed the actual user needing read attribute, only the aspnet process.
 
correct, the actual user does not need rights, but my asp.net identity is:

KAREN-SGIB206P9\roa71

thus, my app is running using this account's rights. is my app setup correctly? should it be running as aspnet?

thanks Stephen. let me know if you would like me to open a ticket since this is getting specific.

thanks, rick..
 
I see 7 other DNN3 installs running fine on this server, I will peek at your web.config and see if I can see anything majorly different here.

Actually yes, open a ticket, I don't know exactly which domain you are having problems with. :)
 
I'm having the same problem with D:\ while uploading custom skins on my sites too.

Any way to fix this yet?
 
i had to manually upload the module via ftp. then i modified the dnn source code to remove the upload code that was breaking due to permission problems. basically, i had to hack it to get my module added.

i still maintain that there are some permission problems. if you can, copy / paste the detail of your error here (including the call stack), that may help.

rick..
 
The only problem may be with some SystemIO commands that could be disabled, but the permissions otherwise are fine :)
 
In case anyone was wondering, this problem has been fixed by Stephen. It was the persmissions on [win5] D:\ that were screwed up by the HSphere updates a few days ago.
 
Back
Top