Many of the errors for Google Drive migrations, particularly Google Drive source migrations, relate to some of Google Drive’s unique characteristics:
- Google applies extensive metadata properties to files, folders and Google docs, many of which affect whether the file can be transferred. These are particularly visible in cases where a file is owned by one user, but physically located in the namespace of another user.
- The identical file – with the same file id and, if applicable, version ids – can be listed in multiple locations throughout the tenant. This typically happens if the file is shared, and the sharees mount that shared file in their /My Drive.
- Rate limiting. Google is one of the stricter enforcers of Rate Limiting. Google docs may be most affected because of the multiple requests needed for not only the file, but also the versions, ACLs and commenters within the document.
Errors Related to Metadata, Breaks in Ownership and Permissions
[Email] does not have permission to download this file: This error typically occurs when:
- a file is shared out with a user via a domain link or group,
- that user mounts the file on their /My Drive, and
- that user does not have permission to download the file, either because the ACL is for viewer/commenter permissions, the user does not have access to list permissions (and therefore, we don’t know whether they have write access to the file), or both.
A hallmark of this error is that if you look at the Collaborators tab for the file that has this error in job history, it will only list the sharee as an inherited “Owner” of the file, because they can’t list permissions for it. That “Ownership” is actually what is inherited down from the sharee’s /My Drive; the true owner of the file is listed as the Source Account in the Details tab.
If you look at the instance of that same file in the Source Account/Owner’s nsid, you’ll note two things:
- The Collaborators tab lists collaborators, including a group or domain link. But the sharee who had the error is not explicitly listed as a user who has access to the file.
- The file in the owner’s nsid will transfer successfully, and will be shared with any groups listed in the Collaborators tab. Note that CFP reports domain links from Google Drive, but does not apply any ACLs for those files.
This error may occasionally occur in other conditions. Contact firstname.lastname@example.org if you have a file that has this error and does not fit the above specifications.
A related error that occurs for externally owned files for the same reason is “The user does not have sufficient permissions for file [file id].”
Failed to export file size: Forbidden; Failed to export file size: Bad Request The first of these errors is generally associated with Google doc exports, while the latter is associated with exporting Google sheets. The root cause is the same:
- the Google file is shared with a user who does not have permission to export it. This frequently happens with Google files that are shared via read-only domain links.
- the user mounts that file on their /My Drive.
- CFP tries to export the file, and Google returns a 403 error and the above message.
Fortunately, the owner of the file will have permission to export it, and generally will have that same file residing in their /My Drive. In that case the file can be exported with no permission issues via that account.
You will also see the error ‘Failed to export file size: Forbidden’ if you try to transfer Google docs that are owned and in the namespace of a user who has been suspended.
File Not Found…: Typically, these files have two characteristics. First, the Source Account, or owner of the file, is different from the NS ID, or namespace in which the file resides. Second, there is a Google field capabilities_canMoveItemOutOfDrive that is set to false. So basically, the namespace user does not have permission to move the file out the current /My Drive, and we cannot transfer the file. Remediating the break in ownership may resolve the issue.
User does not have permission to read revisions of this shared file: Similar to File Not Found, the namespace and account users are different. In this case, the Google field capabilities_canReadRevisions is false, so the namespace user cannot read the versions of the file.
The authenticated user does not have the required access to the file: This can have several causes, but is generally a variant of ‘User does not have permission to read revisions of this shared file.’
Shared files are not included: Files on Google Drive can be shared out with other users, in which case they will appear in the users Shared with Me drive. However, those files can be mounted onto the sharee’s /My Drive – in which case the identical file, with the same ids, will appear in two different physical locations. Cloud FastPath will only transfer the one instance of the file, and share that with the designated users. Other instances of the file will be tagged with the “Shared files are not included” message. This eliminates data duplication on the target as well as excess byte transfer charges.
About Transferring Duplicate Files: It is possible to have two totally different files, with different ids, in the same location. For example, you may have /My Drive/GoogleDoc and /My Drive/GoogleDoc in the same namespace, but they are completely different files with different content. In this case, the first document will be transferred with the original path, while the second document will be transferred with the file id appended to the file name. That’s necessary so we sync the two documents correctly.
There are several types of rate limit errors. The good news is that the vast majority of affected files – and/or their ACLs – will transfer on re-run. In extreme cases – heavily shared files of > 40 ACLs or Google docs with extensive commenters – a third pass may be needed. The important point is that these are not permanent errors and generally resolve on re-run.
Access is denied: This is actually not a permissions error in most cases, but a rate limiting error. That’s because when Google rate limits, it returns a 403 error rather than a 429 error. When these errors are due to rate limiting, they frequently resolve on re-run.
Failed to export file size: This file is too large to be exported: The exporting api provided by Google supports a max size of 10MB for the exported file. Google docs that export to sizes greater than this will generate an error, and must be split up if you want them to export.
The file’s format cannot be migrated…: Google Docs, Sheets, Slides, draw, and a few other Google apps can be exported or migrated in native format. Google forms, maps and other apps cannot be migrated, and are filtered.
Internal Server Error: Some files, notably Google sites, may experience Internal Server errors on export. In instances where the web app allows download of the Google app file, you can try downloading the file to see if it will export, and if so, whether there is an error. Most Internal Server errors are persistent and the file cannot be exported and therefore cannot be transferred.
Unable to access user files; user might not have support for the Google-Drive app: The user probably does not have the Google Drive app enabled for their account. This can be confirmed by checking the user’s app listing at admin.google.com. If the Google Drive app is not enabled, they do not have any storage space enabled.
NOTE: While most users who have the drive disabled have never had it turned on, it is possible to turn the Google Drive app on, store data there, and then later turn it off. CFP cannot access the data if the drive is disabled, but data may still be available and transferrable if the drive is re-enabled.