Issue with Service User Permissions in RepoInit Scripts | Community
Skip to main content
T
test1234567
Level 6
July 31, 2025
Solved

Issue with Service User Permissions in RepoInit Scripts

  • July 31, 2025
  • 1 reply
  • 394 views

Hello Community,

I have created RepoInit scripts to create a service user and grant specific permissions. However, for some reason, I am unable to predict the behavior of the granted permissions. Initially, when the script was deployed to the instance, I observed the following permissions in the content repository:

  • Read: Yes
  • Modify: No
  • Create: Yes
  • Delete: Yes

After several deployments (with no changes made to the script), I started noticing errors in the logs. Upon checking the permissions in the UserAdmin Console, I saw that the "Create" permission was no longer enabled. The updated permissions were:

  • Read: Yes
  • Modify: No
  • Create: No
  • Delete: Yes

Here is the error log that I encountered:

 

ERROR LOG: 2025-07-30 21:25:50.721 ERROR [com.xxx.yyy.aem.core.internal.impl.models.zzzz] RepositoryException while interacting with JCR: /content/project1/en/jcr:content/root/responsivegrid/layout_container_cop/content/layout_container_169/content/layout_container_108/content/navigation_1210280890 javax.jcr.AccessDeniedException: Access denied. at org.apache.jackrabbit.oak.jcr.security.AccessManager.checkPermissions(AccessManager.java:71) [org.apache.jackrabbit.oak-jcr:1.22.20] at org.apache.jackrabbit.oak.jcr.session.NodeImpl$5.perform(NodeImpl.java:320) [org.apache.jackrabbit.oak-jcr:1.22.20] at org.apache.jackrabbit.oak.jcr.session.NodeImpl$5.perform(NodeImpl.java:289) [org.apache.jackrabbit.oak-jcr:1.22.20] at org.apache.jackrabbit.oak.jcr.delegate.SessionDelegate.perform(SessionDelegate.java:207) [org.apache.jackrabbit.oak-jcr:1.22.20] at org.apache.jackrabbit.oak.jcr.session.ItemImpl.perform(ItemImpl.java:112) [org.apache.jackrabbit.oak-jcr:1.22.20] at org.apache.jackrabbit.oak.jcr.session.NodeImpl.addNode(NodeImpl.java:289) [org.apache.jackrabbit.oak-jcr:1.22.20] at com.xxx.yyy.aem.core.internal.impl.models.zzzz.createLinkNode(zzzz.java:336)

RepoInit Script:

Below is the RepoInit script I used:

 

Config Name: org.apache.sling.jcr.repoinit.RepositoryInitializer~retail.cfg.json

AEM Version: 6.5.21

Environment: Adobe Managed Service (Not cloud).

{ "scripts": [ "create path (sling:Folder) /conf/retail-targeting", "set ACL for anonymous\nallow jcr:read on /conf/retail-targeting\nend", "create service user testWriteUser with path /home/users/system/retail", "set ACL on /content/experience-fragments/retail-stores\nallow jcr:read,jcr:write,jcr:addChildNodes,jcr:modifyProperties,jcr:removeNode,jcr:removeChildNodes for testWriteUser\nend", "set ACL on /content/campaigns/web-portal/target-experience/UserExperience\nallow jcr:read,jcr:write,jcr:addChildNodes,jcr:modifyProperties,jcr:removeNode,jcr:removeChildNodes for testWriteUser\nend", "set ACL on /content/project1/en\nallow jcr:read,jcr:write,jcr:addChildNodes,jcr:modifyProperties,jcr:removeNode,jcr:removeChildNodes for testWriteUser\nend" ] }

Could someone check and let me know if you have faced a similar issue? Additionally, could you confirm if there’s anything wrong with the script? My goal is to ensure that the service user has the necessary permissions to perform node creation and modification operations.

Thanks in advance!

Best answer by BrianKasingli

@test1234567 ,

With RepoInit, every deployment re-applies the ACLs you’ve declared for a service user. That means the outcome can change between deployments if the script isn’t consistent or if multiple configurations affect the same user.

The issue where the “Create” permission disappears after several deployments usually happens because RepoInit doesn’t merge permissions — it overwrites them. If you ever deploy a version of the script that doesn’t explicitly list jcr:addChildNodes, for example, that privilege will be removed. Likewise, if another RepoInit configuration or package modifies the same principal, your ACLs can get overridden.

To prevent this, always declare the full set of privileges you want the service user to have on each deployment. Don’t rely on incremental changes. You can simplify by using the aggregate jcr:write privilege, which already includes create, modify, and delete operations.

For example, a reliable RepoInit script could look like this:

{ "scripts": [ "create service user testWriteUser with path /home/users/system/retail", "set ACL on /content/project1/en\n allow jcr:read,jcr:write for testWriteUser\nend" ] }

 If you prefer to be more explicit instead of using the shorthand, you can write:

{ "scripts": [ "create service user testWriteUser with path /home/users/system/retail", "set ACL on /content/project1/en\n allow jcr:read,jcr:addChildNodes,jcr:modifyProperties,jcr:removeNode,jcr:removeChildNodes for testWriteUser\nend" ] }

 

The key is consistency. Each ew configuration, deploy on local. Each local deployment should redeclare the complete ACL set, so permissions don’t drop unexpectedly. After deployment, confirm through User Admin (http://localhost:4502/useradmin) that the service user has the intended access, and monitor your error logs during startup — RepoInit logs will tell you exactly which rules were applied.

This approach ensures your service user always retains the ability to create and update nodes, without privileges silently disappearing after multiple deployments.

1 reply

BrianKasingli
Community Advisor and Adobe Champion
BrianKasingliCommunity Advisor and Adobe ChampionAccepted solution
Community Advisor and Adobe Champion
July 31, 2025

@test1234567 ,

With RepoInit, every deployment re-applies the ACLs you’ve declared for a service user. That means the outcome can change between deployments if the script isn’t consistent or if multiple configurations affect the same user.

The issue where the “Create” permission disappears after several deployments usually happens because RepoInit doesn’t merge permissions — it overwrites them. If you ever deploy a version of the script that doesn’t explicitly list jcr:addChildNodes, for example, that privilege will be removed. Likewise, if another RepoInit configuration or package modifies the same principal, your ACLs can get overridden.

To prevent this, always declare the full set of privileges you want the service user to have on each deployment. Don’t rely on incremental changes. You can simplify by using the aggregate jcr:write privilege, which already includes create, modify, and delete operations.

For example, a reliable RepoInit script could look like this:

{ "scripts": [ "create service user testWriteUser with path /home/users/system/retail", "set ACL on /content/project1/en\n allow jcr:read,jcr:write for testWriteUser\nend" ] }

 If you prefer to be more explicit instead of using the shorthand, you can write:

{ "scripts": [ "create service user testWriteUser with path /home/users/system/retail", "set ACL on /content/project1/en\n allow jcr:read,jcr:addChildNodes,jcr:modifyProperties,jcr:removeNode,jcr:removeChildNodes for testWriteUser\nend" ] }

 

The key is consistency. Each ew configuration, deploy on local. Each local deployment should redeclare the complete ACL set, so permissions don’t drop unexpectedly. After deployment, confirm through User Admin (http://localhost:4502/useradmin) that the service user has the intended access, and monitor your error logs during startup — RepoInit logs will tell you exactly which rules were applied.

This approach ensures your service user always retains the ability to create and update nodes, without privileges silently disappearing after multiple deployments.

    Terms & ConditionsAccessibility statement

    Loading footer...