Archive Extraction Process Step Not working with Lunchers | Community
Skip to main content
R
RinkiSh
Level 2
May 22, 2026
Question

Archive Extraction Process Step Not working with Lunchers

  • May 22, 2026
  • 1 reply
  • 25 views

Hi All, I am trying to use OOTB Archive extraction process step with launcher, but when zip file is having nested folder and files , launcher is not able to extract it properly wheras with manual triggering workflow works as it is triggered by admin.

With launcher I am getting below error org.apache.sling.api.resource.PersistenceException: Can't create valid output path
    at com.day.cq.dam.core.impl.unzip.impl.UnzipServiceImpl.getValidPath(UnzipServiceImpl.java:206) [com.day.cq.dam.cq-dam-core:5.15.190]
    at com.day.cq.dam.core.impl.unzip.impl.UnzipServiceImpl.validateFilePath(UnzipServiceImpl.java:220) [com.day.cq.dam.cq-dam-core:5.15.190]
    at com.day.cq.dam.core.impl.unzip.impl.UnzipServiceImpl.handleFile(UnzipServiceImpl.java:211) [com.day.cq.dam.cq-dam-core:5.15.190]
    at com.day.cq.dam.core.impl.unzip.impl.UnzipServiceImpl.processZipEntry(UnzipServiceImpl.java:159) [com.day.cq.dam.cq-dam-core:5.15.190]
    at com.day.cq.dam.core.impl.unzip.impl.UnzipServiceImpl.processEntries(UnzipServiceImpl.java:127) [com.day.cq.dam.cq-dam-core:5.15.190]
    at com.day.cq.dam.core.impl.unzip.impl.UnzipServiceImpl.extract(UnzipServiceImpl.java:96) [com.day.cq.dam.cq-dam-core:5.15.190]
    at com.day.cq.dam.core.impl.unzip.impl.UnzipManagerServiceImpl.runExtraction(UnzipManagerServiceImpl.java:97) [com.day.cq.dam.cq-dam-core:5.15.190]
    at com.day.cq.dam.core.impl.unzip.job.AsyncUnzipJobExecutor$1.execute(AsyncUnzipJobExecutor.java:119) [com.day.cq.dam.cq-dam-core:5.15.190]
    at com.adobe.granite.jobs.async.commons.AbstractAsyncJobExecutor.process(AbstractAsyncJobExecutor.java:427) [com.adobe.granite.jobs.async:1.1.62]
    at org.apache.sling.event.impl.jobs.queues.JobQueueImpl.startJob(JobQueueImpl.java:359) [org.apache.sling.event:4.3.18]
    at org.apache.sling.event.impl.jobs.queues.JobQueueImpl.access$100(JobQueueImpl.java:60) [org.apache.sling.event:4.3.18]
    at org.apache.sling.event.impl.jobs.queues.JobQueueImpl$1.run(JobQueueImpl.java:291) [org.apache.sling.event:4.3.18]
    at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1144)
    at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:642)
    at java.base/java.lang.Thread.run(Thread.java:1583)
Caused by: javax.jcr.security.AccessControlException: Can't create folder in /content/dam/hydrated-assets/brands
    at com.day.cq.dam.core.impl.unzip.AclPathUtil.getValidSubPath(AclPathUtil.java:105) [com.day.cq.dam.cq-dam-core:5.15.190]
    at com.day.cq.dam.core.impl.unzip.AclPathUtil.getValidPath(AclPathUtil.java:72) [com.day.cq.dam.cq-dam-core:5.15.190]
    at com.day.cq.dam.core.impl.unzip.impl.UnzipServiceImpl.getValidPath(UnzipServiceImpl.java:204) [com.day.cq.dam.cq-dam-core:5.15.190]
    ... 14 common frames omitted

1 reply

S
Adobe Employee
SubbaraoGa1Adobe Employee
Adobe Employee
May 22, 2026

Hello ​@RinkiSh 

We reviewed the behavior and the error stack trace. This does not appear to be a defect with nested folders inside the ZIP itself.

The failure is happening because, when the Archive Extraction Process is triggered through a launcher, the workflow runs under the workflow process/service context rather than an administrator session. In your case, that execution context is not able to create the required destination folder path under:

/content/dam/hydrated-assets/brands

This is why the workflow succeeds when triggered manually by an admin, but fails when started automatically through the launcher.

The key error confirming this is:

javax.jcr.security.AccessControlException: Can't create folder in /content/dam/hydrated-assets/brands

Conclusion

The issue is most likely caused by missing permissions on the target extraction path for the user/service context under which the launcher-driven workflow executes.

Recommended next steps

Please verify that the workflow execution context has sufficient permissions on the extraction target path, including the ability to:

  • read the ZIP asset
  • create intermediate folders
  • create assets/files under the target folder
  • save changes in that subtree

In particular, please review permissions on:

  • /content/dam/hydrated-assets
  • /content/dam/hydrated-assets/brands

Once the required access is granted, the launcher-based extraction should work for ZIPs containing nested folders as well.

If needed, we can also help review the workflow model / launcher configuration and validate the effective permissions on the target path.

R
RinkiShAuthor
Level 2
May 22, 2026

I gave jcr:all permission to dam-update-service, workflow-process-service and workflow-service to /content/dam path but it’s still same error and the thing this process this OOTB right , it will be complex to change anything.

S
Adobe Employee
SubbaraoGa1Adobe Employee
Adobe Employee
May 26, 2026

Thanks for checking that and for granting jcr:all to dam-update-service, workflow-process-service, and workflow-service.

Based on the behavior, this does not look like a limitation of the OOTB Archive Extraction step itself for nested ZIP content, because the same archive extracts successfully when triggered manually by an admin. That tells us the extractor can handle the ZIP structure, and the failure is more likely tied to the execution context/permissions used when the workflow is started through the launcher.

The error is still very specific:

javax.jcr.security.AccessControlException: Can't create folder in /content/dam/hydrated-assets/brands

So the next focus should be the effective permissions on the exact target path and child folder creation path, not just broad permissions on /content/dam. In AEM, inherited ACLs, explicit deny entries, or restrictions on subpaths can still block folder creation even when higher-level permissions appear broad.

Since this is an OOTB capability, we are not recommending changing the OOTB process step as the first approach. Instead, we recommend validating:

  1. the effective permissions on /content/dam/hydrated-assets/brands and the nested child paths being created,
  2. whether there are any deny ACEs or path restrictions on that subtree,
  3. and which effective execution context is being used by the launcher-driven asynchronous extraction.

If those checks confirm that the launcher execution context has the required create/write access on the exact destination subtree and the issue still reproduces, then this would be a valid case to take forward as an OOTB product issue rather than a customization request.

As a temporary workaround, manual admin-triggered extraction can continue to be used while the permission path is being validated.

Terms & ConditionsAccessibility statement

Loading footer...