Thank you.  It turned out to be a permissions issue.  The user had to be set as a member on the folder where the Content Fragments were being Created/Deleted via the API.  This wasn't the case before.

We have been using the Assets HTTP API to Create and Delete content fragments and have just started receiving an error message only when sending a DELETE post.  We are on AEM 6.5.21.  Does anyone know why this would just start happening?    "status.message": "Source does not support deletion", "stat...

Thank you for your help.  The issue was in fact related to the dispatcher config.  The solution was not intuitive at all but the correct configuration ended up looking like this:/0404 { /type "allow" /method "GET" /path "/content/dam/[customfolder]/*" /suffix '^/subassets/.*' /extension '(mov|mp4|mp...

Also confirmed the issue does not happen in local - the subassets are working showing up in both Author and Publish.

We are on-prem.  We are currently on Service pack 21 and also using Asset Share 3.8.4.

Yes I am able to see the subassets via crxde on both Author and Publish.  So the subassets are there in Publish but still throwing 404s when we present them to the page.  In Author we do not receive 404s.

I was able to get some subassets to publish via tree activation but we are still getting 404's on publish.  Are there certain permissions needed to make subassets available on publish?

We have created a feature that needs access to each asset's subassets.  But our subassets are not showing up in publish.  We do not have a publish option on the subassets folder.  Treeactivation does not seem to be working either.  And when we ran the subassets through the ActivationModel workflow, ...

We found the issue that is causing this to happen.  Starting with service pack 18, the lodash clientlib has been removed from AEM.  We had a piece of code with a dependency on lodash, and without it there, the search could not function properly.

I saw that other thread before posting my question and based on the comments in there, it appears this is an issue with the product, since someone was able to reproduce the issue on a vanilla instance running service pack 15.