User cannot persist changes via Assets API

[jlanssie-tme]

I have a user that can perform CRUD operations via the UI.

He is inside the OOTB Contributors group and has permissions for a specific dam path: `/content/dam/data`, where he can create, read, update and delete Content Fragments. 

When this same user tries to perform CRUD operations over the Assets API, AEM throws an error

13.03.2025 09:10:36.149 *WARN* [141.135.37.92 [1741857036142] POST /api/assets/data/retailers/postman/postman-team-member HTTP/1.1] com.adobe.granite.rest.impl.servlet.PostRequest Exception during request processing.
org.apache.sling.api.resource.PersistenceException: Unable to commit changes to session.
	at org.apache.sling.jcr.resource.internal.helper.jcr.JcrResourceProvider.commit(JcrResourceProvider.java:519) [org.apache.sling.jcr.resource:3.0.18]
	at org.apache.sling.resourceresolver.impl.providers.stateful.AuthenticatedResourceProvider.commit(AuthenticatedResourceProvider.java:240) [org.apache.sling.resourceresolver:1.10.0]
	at org.apache.sling.resourceresolver.impl.helper.ResourceResolverControl.commit(ResourceResolverControl.java:531) [org.apache.sling.resourceresolver:1.10.0]
	at org.apache.sling.resourceresolver.impl.ResourceResolverImpl.commit(ResourceResolverImpl.java:1031) [org.apache.sling.resourceresolver:1.10.0]

The HTTP Request gets a response

{
    "class": [
        "core/response"
    ],
    "properties": {
        "path": "/api/assets/data/postman-test",
        "parentLocation": "/api/assets/data.json",
        "referer": "",
        "changes": [],
        "location": "/api/assets/data/postman/postman-test.json",
        "status.message": "Unable to commit changes to session.",
        "status.code": 500
    }
}

 
The issue is not authentication. Adobe Experience Manager gets the request fine. It is not the payload or the Content Fragment either, or I would get a different kind of error. 

The Assets API also works fine on lower environments, Development & Staging. 

So, I am left wondering what the issue could be. I assume it is permissions as it is the ResourceResolver that fails to commit the changes, as it is mentioned in the logs. But I cannot wrap my head around why this works perfectly fine in the UI, but fails over the API.

[giuseppebag]

Please verify if the user and/or their corresponding user group (http://instance:port/security/groups.html) has write permissions for that folder. From the messages I can assume there is a resourceResolver.commit()/sessions.save() function that fails due to insufficient write permissions.

[jlanssie-tme]

As I mentioned in the description, the user can do it via the UI. It only fails on the Assets API, so your suggestion is not relevant.

[AmitVishwakarma]

Hi @jlanssie-tme ,

It does sound like a permission issue, but since the user can perform CRUD operations via the UI, the problem might be related to API-specific permissions or missing system user mappings. Here are a few things you can check:

1. Check ACLs for API Requests
     - Ensure the user explicitly has jcr:write and replicate permissions on /content/dam/data for API access.
     - Check permissions via Useradmin Console (/useradmin) or CRXDE (/crx/de).
      - Verify that the group’s permissions propagate to the API requests.

2. Validate API-Specific User Permissions

    - API calls might be executed under a different context than UI interactions.
    - Check if the service user mappings (used by Assets API) have the necessary access.
    - Try assigning the user to the dam-users or dam-api-access groups and test again.

3. Check for Overlays or Custom Code Restrictions

    - Custom Sling filters, servlets, or workflows could be interfering with API write operations.
    - Look for any custom error handling that could prevent resourceResolver.commit().|

4. Compare Configuration Between Environments

Since this works in Development & Staging, compare OSGi configurations, ACLs, and user permissions in Production.
Specifically, check:

      - Apache Sling Resource Resolver Factory (/system/console/configMgr)
      - Granite Operations Settings
      - Any API request restrictions (Apache Sling Authentication Service)

5. Try Debugging with a Different User

    - If possible, test the API using an admin user (to rule out permission issues).
    - If it works, then it’s definitely a permission issue with the original user.

If the issue still persists, enabling debug logging for org.apache.sling.jcr.resource might give more insight into why commit() fails.

Best Regards,
Amit Vishwakarma

[jlanssie-tme]

As it turns out, it is also failing when we give our user "Administrators" permissions. This issue is being followed up at Adobe Case #E-001575531.

[jlanssie-tme]

Great suggestions! But nothing came out of the preliminary investigations.

[kautuk_sahni]

@jlanssie-tme Did you find the suggestions helpful? Please let us know if you need more information. If a response worked, kindly mark it as correct for posterity; alternatively, if you found a solution yourself, we’d appreciate it if you could share it with the community. Thank you!

[Uppari_Ramesh]

Hi @jlanssie-tme , before saving the changes can you try refreshing the session and also check if node is not in checked in state.

[jlanssie-tme · Accepted solution]

As it turned out, the Granite Assets REST API bundle was not active. There was a dependency issue on a certain Adobe-bundle.