Reputation: 67
Problem:
Only one of our three Office 365 tenant, a Graph call fails with an itemNotFound error. The other two tenants works as expected.
Case:
When using the Graph API to access a folder on a SharePoint site, we get the following "itemNotFound" error: { "error": { "code": "itemNotFound", "message": "The resource could not be found.", "innerError": { "request-id": "4ea1730c-1b1d-4993-8335-4e10cc3b47c1", "date": "2020-04-27T09:15:37" } } }
Query Information:
This is the final query that fails: https://graph.microsoft.com/v1.0/sites/54929188-6c44-4555-a85b-27a698b9b572/drive/root:/InvestmentTemplate
To find information to "build" the query, that fails, we are using this query to find the site id:https://graph.microsoft.com/v1.0/sites/testnrep.sharepoint.com:/sites/DocumentTemplates
To recreate test data:
The full folder url: https://ZXY.sharepoint.com/sites/DocumentTemplates/Shared%20Documents/InvestmentTemplate
Upvotes: 0
Views: 1819
Reputation: 226
Re-stating comment above as answer as this appears to address your scenario.
I reproduced a similar scenario in my lab environment. The query succeeds when running as a tenant administrator. Query fails as a normal user. I removed all permissions granted to Graph Explorer and added them back one by one. Once I granted Files.Read.All (not just Files.Read) for the non-admin user I was then able to successfully query a similar endpoint.
As for the ":/" syntax, yes that is common to use a ":" when specifying a relative location within the siteUrl or path in a document library. See examples for site-id using relative URL or relative path within document library.
Upvotes: 0