Copy folder from local machine to other server RRS feed

  • Question

  • User1623224911 posted
    Hi im having trouble with our site,  i have to copy data from one server(web server) to another server. At the moment i get this error:

    Microsoft VBScript runtime error '800a0046'

    Permission denied

    /file/1/main.asp, line 26

    I have created a share with the proper permissions for the iusr_ account and for a domain\user account and the filesystem permissions are good too. Can someone shed some light on my problem?


    Dim root, Code, Projectname, ProjectCode

    root = "\\servername\sharename\directoryname\" & projectname & "-^-" & ProjectCode

    CheckFolder root

    Sub CheckFolder(folder)
        Set objFSO2 = Server.CreateObject("Scripting.FileSystemObject")
        if  not objFSO2.FolderExists(folder) then
            folder = mid(folder,1,len(folder))
            objFSO2.CopyFolder "c:\directory" , folder , false
            end if
        set objFSO2 = nothing
    end sub

    Monday, August 15, 2005 4:51 AM

All replies

  • User-823196590 posted
    See the section on "Synchronizing the IUSR_machine accounts":
    Monday, August 15, 2005 8:47 AM
  • User1623224911 posted
    Hi thanks for the quick reply.  I was under the impression that since my 2 servers are in the same domain, that I would be able to define a domain account that had  the proper permissions to access the files and copy them to the other location. Is this possible? or do i have to use anonymous access and the iusr_ account?
    Monday, August 15, 2005 10:29 AM
  • User-823196590 posted
    A domain account would work but it's not clear how you're using it.  On way is to use a domain account as the anonymous user.
    Monday, August 15, 2005 11:07 AM
  • User1623224911 posted
    OK, Lets see if I can explain the situation better. When I try to copy from Web-server A to File-server B, I get a permission denied. I would like to define this to run  as a domain user, if not possible then we have to call a script that does a net use as a different user and performs the copy action. The user is defined in global.asa but I think the webserver is using other credentials (thats why i tried setting the permissions for the iusr account aswell). Both servers are windows 2003 servers.

    PS Thanks again for your quick reply

    Monday, August 15, 2005 11:25 AM
  • User-1853252149 posted
    This also depends on how you're authenticating to the system.  The script may be running under the anonymous user account, or it may run under the account of the user that was authenticated.  One way that may get what you need is to make the anonymous user account a domain account.  You can create a domain account for IIS, then in IIS go to the properties for the web server, directory security tab, access and control, and set the account to be used.  Grant that same account the necessary access on the other system, and use a UNC convention to get there, not a mapped drive letter.

    Monday, August 15, 2005 11:56 AM
  • User-823196590 posted
    Yes, and the link I provided pretty much explains this.
    Monday, August 15, 2005 2:54 PM
  • User1623224911 posted
    Ok, ive gotten it running now under anonymous acess, but i want my users to be authenticated. Right now I have the copy action working properly with the above code, but only anonymous access. How can I get my users authenticated(even plain text would be acceptable!) but have the copy action run under other credentials??
    Friday, August 19, 2005 6:16 AM
  • User-823196590 posted
    Remove anonymous access and the user's credentials will be used instead.  make sure they have NTFS change permissions to the folder.
    Friday, August 19, 2005 9:54 AM
  • User1623224911 posted
    I've tried removing anonymous access, the problem is that i  would have to give the users Full Control perms because we need to do some setting of security on the files that have been copied. That is why i wanted to define the job to run as a (predefined)user with full control on the target machine, so that my users cannot screw up the rest of the security in this folder. If this cant be done ill have to use tomkmvp's solution above.
    Friday, August 19, 2005 11:20 AM