Replication User Permissions for Pages with Closed User Groups

Hi ​@user06081 ,

​You shouldn't need a custom transport user here—the out-of-the-box replication-receiver system user on Publish is already pre-configured with the exact repository privileges and Oak exclusions needed to process incoming replications seamlessly. Using OOTB avoids managing custom transport permissions across environments.

Why This Error Happens?

​When Closed User Groups (CUG) are enabled on a page, Apache Jackrabbit Oak creates a rep:cugPolicy node under jcr:content. Oak treats CUG as a strict access gate: even if a user has jcr:all or rep:write granted via regular ACLs on /content, Oak denies jcr:read and write access unless that user is explicitly in the CUG or excluded from CUG evaluation. Because Oak cannot read the tree for that user, it throws the above error

So few solutions:

1. Use the ootb replication receiver user

2. Add the custom user you created to administrators group in publisher

3. Add the custom user to cug exclude group as below:

​On Publish, go to System Console (/system/console/configMgr).

​Open Apache Jackrabbit Oak CUG Configuration (org.apache.jackrabbit.oak.spi.security.authorization.cug.impl.CugConfiguration).

​Add your custom replication username (or group) under CUG Excluded Principals (cugExcludedPrincipals)

Hi ​@user06081,

Building on what Shashi shared, one thing worth flagging before you pick an approach: option 2 (adding your custom user to the administrators group on Publish) works, but it’s worth avoiding in production. administrators bypasses all permission checks repository-wide, not just CUG, so you’d be handing a transport/service user full read-write over everything on Publish, a much bigger blast radius than the problem you’re solving. It’s fine for a quick local test, not something I’d ship.

Also worth knowing: the OOTB replication-receiver user isn’t automatically exempt from CUG either. It only avoids this error if it’s already listed in cugExcludedPrincipals (or is a member of a group that is) some AEM 6.5 environments come with that pre-wired, some don’t, depending on how CUG was set up. So if you switch to replication-receiver and still see the same IllegalStateException, that’s why you’d add it to cugExcludedPrincipals the same way as your custom user.

That makes option 3 the actually durable fix regardless of which user you use. One caveat on it though: cugExcludedPrincipals is a single global OSGi config — anything you add there bypasses CUG evaluation for every CUG-protected node in the repo, not just the pages causing this error. That’s usually fine for a dedicated replication/transport user since it’s not an interactive login, but don’t reuse that same user or group for anything else, or you’ve quietly punched a hole through every CUG on the instance.

So: replication-receiver (or your custom user) + cugExcludedPrincipals is the right combination, just make sure that principal is scoped to replication only.

Also, these are the correct permissions the transport user needs on the publish instances to allow replication of pages with closed user groups.

If you also want to use an Agent User Id, these are the correct permissions that user needs on the author instances to gather the pages for publication.