Child Item

Large number of new errors when making write actions via Dropbox API

Hi folks,

We’re having some trouble with our Dropbox API integration and getting new errors from the Dropbox API.

Some backstory: we’ve been using the Dropbox API to manage shared folders across our company, both creating/deleting shared folders as well as adding/removing users to those shared folders. We use the API via Python code on our end.

This automation runs daily, so we have a lot of ongoing Dropbox API traffic.

Starting Tuesday this week we have been getting a significant number of new errors from the Dropbox API, preventing our automation from running successfully. For example, when we call `create_folder`, we get the following error:

“{'error_summary': 'path/no_write_permission/.', 'error': {'.tag': 'path', 'path': {'.tag': 'no_write_permission’}}}”

While nothing changed in terms of users or access permissions on our end, to be safe we generated new access and refresh tokens, and received these scopes back:

account_info.read file_requests.read file_requests.write files.content.read files.content.write files.metadata.read members.read sharing.read sharing.write team_data.content.read team_data.governance.read team_data.governance.write team_data.member

We also confirmed that the user associated with the API requests is a “Team Admin” — so should have all of the permissions required to take these actions.

Has something changed in the Dropbox API permissions side of things that is preventing previously-successful write operations from working? Looking at our monitoring this is now happening frequently.

Find more posts tagged with

API

Abuse

Accepted answers

lfranchi_pilot

Followup here as we've now resolved this issue and want to share our findings if anyone else runs into the same problems:

The issue ultimately turned out to be the lack of the Dropbox-API-Path-Root header. However, even after including it still failed the same way because we didn't JSON encode the contents of the header prior to handing things off to our HTTP library. We also never were able to (intentionally or accidentally) generate the errors documented in https://www.dropbox.com/developers/reference/path-root-header-modes so it was difficult to diagnose we were not using the header properly.

All comments

Здравко

Hi @lfranchi_pilot,

Your error doesn't come from missing scopes. 😉 There is another error that comes in place for missing scopes - "missing_scope". Currently, this is not the case.

Your error denotes that you don't have permission to create regular folder on the place where you try, not something else! There may be different reasons, but typical are a try to create subfolder in a folder where user doesn't have write permission or try create regular folder on place where, according user' account, it's impossible (in team root scope for some accounts). Check the permissions that user (likely your account) has and if they changed recently (including related to possible account type change).

Hope this gives direction.

Greg-DB

@lfranchi_pilot As Здравко said, this error does not indicate a scopes issue, but rather a file/folder permissions issue. It sounds like your team may have recently migrated to the updated team space configuration, which would update your file/folder setup. Please refer to the Team Files Guide for information on how to interact with team content in a team space using the API.

lfranchi_pilot

@Greg-DB Thanks for the response!

We followed the guide you linked, and have some more information, but things do not work consistently still.

Using the /files/list_folder API endpoint only returns 100 team folders. Our organization makes heavy use of team folders -- we have over 500 of them. Prior to the team spaces migration our team admin account had access to all 500+ of them. Is there a limit that got put in place for team spaces?
Even for the team folders in which we have access (as per /files/list_folder), we cannot create new folders in them. Both /files/create_folder_v2 and /sharing/share_folder fail with a no permissions response.
We did not used to have the Dropbox-API-Path-Root header in our requests. We added it in, but it does not seem to have any effect on the responses we receive. We set the header as {".tag": "root", "root": "<root_namespace_id>"}, with <root_namespace_id> coming from the /users/get_current_account API endpoint.

Does this provide some more info that could help narrow down the root cause? At the end of the day we're seeing significant errors in using Dropbox API in the way we were using it pre-team-space-configuration.

Greg-DB

@lfranchi_pilot I see you only mentioned using /2/files/list_folder, so make sure you've also implemented /2/files/list_folder/continue as documented. You're not guaranteed to get everything back in one call.

Using the Dropbox-API-Path-Root allows you to set a different root for an API call. For example, you can use that to list the contents of the team space by setting the root for the call to the team space. That would make the results for /2/files/list_folder[/continue] relative to the team space, for example. If your team previously did not have a team space, that would not have been necessary at the time, but it is necessary whenever you wish to access the contents of a team space.

As for any specific issues you're seeing, we'll be happy to help, but we'd need more detailed information to be able to investigate and advise accordingly. Please share the specific steps/code/parameters you're using when seeing any particular issue, as well as the unexpected error/output. Be sure to redact the access token though. Feel free to open an API ticket if you'd prefer to share privately.

lfranchi_pilot

Followup here as we've now resolved this issue and want to share our findings if anyone else runs into the same problems: