User cannot persist changes via Assets API

Question

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 error13.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.

jlanssie-tme · Accepted Answer

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

AmitVishwakarma · Answer

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 EnvironmentsSince 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

Sign up

Login with SSO

Login to the community

Login with SSO