AEM system folders reappear after deletion
Certain folders in AEM reappear after deletion — often after a Cloud Manager deployment, an instance restart, or use of a system feature — because they’re system-generated, feature-required, or reintroduced by custom code at every deployment. AEM depends on these paths (created by repository initialization, product features, Dynamic Media activation, or Cloud Manager functional testing), so permanent deletion isn’t supported. Hiding the non-deletable folders with ACL permissions, and removing genuinely custom code-deployed folders from the repository, is the correct way to keep them out of authors’ view without breaking product functionality.
Description description
Environments:
- Adobe Experience Manager as a Cloud Service (AEMaaCS)
- AEM Managed Services
- AEM Assets and Dynamic Media
- Cloud Manager pipelines
Issue/Symptoms:
- Folders appear again after deletion with a “recently created” timestamp.
- Deleting Projects or Quarantine succeeds visually, but the folder reappears after a restart or the next deployment.
/content/campaigns,/content/outbound-marketing, and/content/test-siteare recreated during each pipeline run.- The Dynamic Media folders
_CSSand_DMSAMPLEshow up in search results and can’t be removed.
Root cause:
AEM includes several system-managed or feature-required folder paths created by repository initialization (repoinit), product features, Dynamic Media activation, or Cloud Manager functional testing. These nodes are automatically recreated during deployments or at runtime. Because the product depends on their presence or assumes their existence for backward compatibility, deletion isn’t supported. Code-deployed custom folders behave the same way, because the code package reintroduces them at every deployment.
How to confirm
- Identify the folder type — system folder, integration root, Dynamic Media system folder, Cloud Manager test folder, or code-deployed folder — by comparing the folder name and path to those categories.
- If the folder doesn’t match any known category, it’s likely code-deployed. Check the Cloud Manager Git repository for the path to confirm the code reintroduces it.
Resolution resolution
Follow these steps to resolve the issue:
- Hide non-deletable system folders using ACLs. Go to Tools
>Security>Permissions>Add ACE, enter the folder path (such as/content/dam/projects,/content/campaigns,/content/outbound-marketing, or/content/test-site), and set the permission type to Deny (For example:jcr:read) for the relevant user groups. Log in as a user in the target group and confirm the folder no longer appears. If it’s still visible, confirm the ACE was created on the correct path and that inherited permissions aren’t granting access. - For code-deployed folders, remove the path from the codebase. Search your Cloud Manager Git repository for the folder path, remove it, and redeploy via the pipeline. Re-run the pipeline and check
/content/damto confirm the folder doesn’t return. If it reappears, engage your development team to trace other modules that create the path. - Leave the Dynamic Media system folders (
_CSS,_DMSAMPLE) in place. Don’t delete them via CRXDE — they’re required for Dynamic Media viewer functionality. If they clutter search results, adjust the search filters or user permissions so users no longer see them, and confirm Dynamic Media previews continue to work. - Leave
/content/test-sitein place, since Cloud Manager pipeline tests require it. Don’t delete it; apply an ACL to hide it from authors instead. Confirm the next Cloud Manager run still passes its functional tests — a missing folder causes a 404 in those tests.
Validation
- Confirm the folder is no longer visible to the target user groups but remains visible to administrators.
- Confirm the next Cloud Manager deployment doesn’t remove or override the ACE permissions.
- If the folder was code-deployed, confirm it no longer reappears after a pipeline run.