onedrive-api-docs: Unexpected behavior for AppFolder permissions

I created an app with Files.ReadWrite.AppFolder permission only. Request to: https://graph.microsoft.com/v1.0/drive/special/approot Response: 404, and the AppFolder is not created in my Onedrive.

The documentation states:

“OneDrive creates your app’s folder in the user’s Apps folder, located in the root of the user’s OneDrive, when your app makes the first call to the folder using the special folder namespace. Below are the most common calls your app can make to create the folder for the first time.”

So my AppFolder should have been created and not return 404.

If I try the exact same process after adding the Files.ReadWrite.All permission the request success and return the expected response:

{
    "@odata.context": "https://graph.microsoft.com/v1.0/$metadata#drive/special/$entity",
    ...
    "folder": {
        "childCount": 0
    }
}

and my AppFolder is successfully created. Isn’t the whole point of the Files.ReadWrite.AppFolder permissions to avoid requiring full read/write access to our users?

About this issue

Original URL
State: closed
Created 7 years ago
Reactions: 8
Comments: 23 (5 by maintainers)

Most upvoted comments

I’m not sure how you can close this and somehow label it “not a bug it’s a yet to be implemented feature”. Your public documentation doesn’t even mention the fact that the appFolder scope is not available on OneDrive Business. When both share the same API but yet dependent on the kind of plan the end user chooses that same API behaves entirely differently and that behavior is undocumented, I’d be hard pressed to find anyone who would call this anything other than a bug.

Please reopen this issue, this smacks of nothing more than the overused “it’s a feature, not a bug” scapegoat.

+15

justinformella on Sep 6, 2019

I too have just experienced this same issue. Requesting Files.ReadWrite.AppFolder gives me access denied when I try to access my app folder via drive/special/approot. Only when I request Files.ReadWrite.All am I finally able to access my app folder.

Like OP said, this kind of defeats the point of having a sandboxed app folder if a user needs to give me total access for me to write to it. Hoping this gets fixed.

Also, I believe the documentation here should be updated to reflect the new naming of app folder scopes: https://dev.onedrive.com/misc/appfolder.htm

onedrive.appfolder -> Files.ReadWrite.AppFolder

moughxyz on Sep 3, 2017

February 2018, still have this issue. Hope it will get fixed soon.

incoming-th on Feb 11, 2018

I am still seeing this issue in 2023 with my users. Has the fix been ported to the Android auth libraries?

Digipom on May 5, 2023

OK, so here’s what the state of the world is:

OneDrive Consumer had an issue whereby provisioning wouldn’t work when the Files.ReadWrite.AppFolder scope was the only one present, but that should now be fixed. To my knowledge OneDrive Consumer should be working as expected so please let me know if you’re seeing anything that contradicts this.
OneDrive Business does not support Files.ReadWrite.AppFolder (see these remarks). We want to fix this so that it aligns with how OneDrive Consumer behaves, but it’s a non-trivial change.

If support for OneDrive Business is something that you’d really like to see I’d suggest upvoting any appropriate asks on our uservoice page (or creating one if there aren’t any already).

ificator on Feb 13, 2018

The issue is still there for v4, Files.ReadWrite.AppFolder works for most users but for some (ODC) full RW access is the only workaround.

VitalyKnyazev on Jul 9, 2023

@komikoni I think, this issue is still not fixed. Currently you can just vote on UserVoice so that it get more priority.

barisbikmaz on Jan 13, 2020

We managed to move it back to the developer area so you should be able to vote on it again!

ificator on May 16, 2019

@ificator had the bug with both, ODC and ODB

nicolasbeauvais on Feb 13, 2018