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:
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:
Here is the error log that I encountered:
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).
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!
Solved! Go to Solution.
Views
Replies
Total Likes
@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.
@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.
Views
Likes
Replies