DocumentationExperience Cloud KCS

Resolving OakAccess0000 access denied errors during MSM rollout in AEM as a Cloud Service

Last update: September 10, 2026

This article explains how to troubleshoot and resolve OakAccess0000 access denied errors that occur during Multi-Site Manager (MSM) rollout operations executed by a service user or technical account in Adobe Experience Manager (AEM) as a Cloud Service.

Description description

Environment

Adobe Experience Manager as a Cloud Service (AEMaaCS) (all versions)

Issue/Symptoms

  • MSM rollout operations, such as those triggered by a custom workflow process, fail with an error similar to:

    javax.jcr.AccessDeniedException: OakAccess0000: Access denied

  • The error occurs during the commit phase of the MSM rollout, specifically during the session.save() operation.

  • The service user or technical account executing the workflow appears to have comprehensive permissions on the relevant content paths.

Cause

This error occurs when the service user or technical account lacks effective permissions because of missing privileges or Deny Access Control Entries (ACEs) on one or more nodes affected by the MSM rollout operation. Oak enforces the denial at the composite nodestore layer during commit validation rather than through standard ACL checks. The error can appear in PermissionValidator.childNodeDeleted when the operation attempts to remove a child node without the required permissions.

Resolution resolution

Follow these steps to resolve the issue:

  1. Identify the principal executing the MSM rollout commit operation. Confirm that the service user or technical account is the session principal performing the commit.

  2. Review effective permissions on all paths involved in the MSM rollout. In AEM, go to Tools > Security > Permissionsand inspect the account’s effective permissions on:

    • /content/dam/... (source and target Content Fragment nodes)
    • /conf/global/settings/wcm/msm and /conf/<project>/settings/wcm/msm (MSM configuration nodes)
    • Any blueprint or live copy page structures under /content/... if page-level MSM is involved
    • /var/workflow/instances/... and /var/workflow/models if the workflow writes metadata

Ensure that the account has at least the following privileges:

  • jcr:read
  • jcr:write
  • jcr:removeNode
  • jcr:versionManagement
  • jcr:lockManagement
  1. Check for Deny ACEs or missing privileges. Verify that no Deny Access Control Entries exist for the service user or its groups on any involved path or parent path. Confirm that all required privileges are granted, either directly or through group memberships.
  2. Adjust ACLs only where needed. If the error logs identify a specific denied path, update permissions only on that path instead of granting broad permissions to groups such as workflow-users or to system paths in general.
  3. As a diagnostic step, temporarily add the service user or technical account to an administrative group and retry the rollout. If the operation succeeds, the result confirms an ACL or permission-related issue. Remove the elevated permissions immediately after testing.
  4. After making the required changes, retry the MSM rollout operation and verify that it completes successfully.
recommendation-more-help
experience-cloud-kcs-help-kbarticles