Record the exact denied path, operation and error. Identify whether the request needs read access, execution or write access, and which IIS identity performs it. Keep a record of the current access-control entries and inheritance before making changes.

1. Open the domain Files page, locate the affected file or directory and inspect Change Permissions.
2. Compare the relevant user or group with the website application-pool identity and Plesk-managed account. Ask the administrator to confirm the identity when it is unclear.
3. Grant only the required rights at the narrowest suitable directory. For example, an upload directory may need modification while application code normally does not.
4. Review inherited and explicit deny entries. Do not replace all child permissions recursively unless you have assessed every affected object and have a recovery record.
5. Save the targeted change and repeat one controlled application operation. Check whether the application tries to write somewhere unexpected because of a configuration error.

Confirm the operation succeeds and unrelated files remain protected. Test that a web request cannot read private configuration or upload executable content into an unrestricted public location. Review the application error log after the change.

If access is still denied, inspect the effective identity, inherited ACLs, locked files and security software events. Do not keep adding broader groups. Restore the recorded ACL if the change weakens isolation or affects another site. For damaged Plesk-managed permissions across many paths, use the supported administrator diagnostic and repair workflow after backup rather than improvising a recursive permission reset.

• Configuring a dedicated IIS application pool in Plesk
• Using Plesk Repair diagnostics before making repairs
• Hosting an ASP.NET Core application on Plesk for Windows
• Checking local and external mail routing on Plesk for Windows

• Plesk: Setting File And Directory Access Permissions