Symptoms

Various Windows Shared Hosting provisioning tasks fail in POA with the error message 'Access is denied'. E.g. POA cannot turn off FTP access for service user on Windows webspace:

Task name:        Turn off FTP access for Hosted Service User 1008 on host
'web1.provider.com' (host_id=111).
Last execution output: Exception during execution of MPF request: 'Access is
denied.
[<response><errorContext description="Access is denied." code="0x80070005"
executeSeqNo="2">
<errorSource namespace="NTFSManager"
procedure="changeFileOwner"/></errorContext></response>]'.

Cause

In the failed task properties it is seen that failed procedure is changeFileOwner in the NTFSManager namespace, so most probably the reason of problem is lack of permissions to access some resources on file system.

Resolution

Log into MPS server and catch the MPF request which POA is executing in the task using the 'TraceView' utility, the request will looks like this:

<execute impersonate="1" namespace="NTFSManager"
procedure="changeFileOwner">
 <after destination="data" destinationPath="log" source="context" />
 <after destination="data" destinationPath="log" source="executeData" />
<executeData>
 <forceQuotaOveruse>true</forceQuotaOveruse>
 <host>web1.provider.com</host>
 <ignoreBadCurrentOwners>false</ignoreBadCurrentOwners>
 <newOwner>LDAP://AD01.provider.com/CN=w0012253,OU=S001002735,OU=R0000000423,O
U=Hosting,DC=provider,DC=com</newOwner>
 <path>D:\CustomerData\webspaces\webspace_0012253\</path>
<currentOwners>
 <owner>LDAP://AD01.provider.com/CN=thename,OU=S001002735,OU=R0000000423,OU=Ho
sting,DC=provider,DC=com</owner>
</currentOwners>
</executeData>
</execute>

The request above is going to change ownership on the folder D:\CustomerData\webspaces\webspace0012253_ and fails.

Install 'Process Explorer' from http://sysinternals.com/ on the host web01.provider.com and check what process does hold the folder, most probably it will be IIS process w3wp.exe.

Try the following solutions:

  1. Find website in webspace #12253 in IIS Manager and stop it.
  2. Run the task.
  3. Start website.

If the procedure above does not help, try to stop IIS on web1.provider.com, re-run the task and start IIS back.

Also check that pem_admin - the user under which such requests are executed, has the permissions to access CustomerData share:

  1. Go to the disk where CustomerData folder is located(Typically, D:\),
  2. Right-click CustomerData folder > Properties > Sharing > Advanced sharing,
  3. Ensure that folder is checked, and select the PEM_<GUID> from name dropdown,
  4. Click Permissions and check that user pem_admin has read/write access to the share

See KB article #121830 for more details on restoring permissions on IIS hosts.

Internal content