Google Drive Error: NotFound[404]

Problem

My Google Drive to Google Drive migration is resulting in failed users with NotFound[404] errors.

Error

[2020-09-15 21:35:32.7501] [GMailUserExporter] [Error] [1] [user.name] [] Unexpected exception when processing user. Unexpected exception processing import. Message is: Not retrying NotFound[404] error cloud.solutions.Migration.Core.ImportThreadException

Cause

In almost all cases this occurs when all users and groups (and all group memberships) have not been created prior to the Drive migration, and thus, the required permission cannot be resolved.

Please ensure to read our best practices for Google Drive migrations here (and for subsets of users here). 

Solution

This error occurs when CloudM Migrate is trying to process an item (typically a folder) for a migrating user, seeing that they have permission to it on the source on export, but that permission cannot be resolved in the destination.

In almost all cases this occurs when all users and groups (and all group memberships) have not been created prior to the Drive migration, and thus, the required permission cannot be resolved.

Drive Readiness Tests

Before you start a migration of this kind, you will encounter a prompt (below). It is highly recommended to utilize Drive Readiness which will help you to ensure the prerequisites are met prior to migration, thus, preventing possible 404s:

You should always provision all of your users and groups before performing a Drive migration. This is required to ensure all sharing and Drive hierarchies are preserved correctly during the migration. If you are renaming users as part of the migration, you must make sure all import and export names are present and have been updated to the names in the new system.  You should ensure you have provisioned all of your users before migrating your groups, and all addresses are mapped in the address replacements CSV.

Typical Causes:

(1) A user is shared a folder on the source via a Google Group which has not been created on the destination prior to the migration.

To resolve this, ensure that the group exists on the destination, including all the same members as the source.

(2) A user is shared a folder on the source via a Google Group which exists in the destination, but they were not added as a member (explicitly).

To resolve this, ensure that the group exists on the destination, including all the same members as the source.

(3) A user is shared a folder on the source via a sub-domain on the source which has not bee replaced according to domain replacements.

*If 'Replace CSV Addresses Only' is enabled, then your domain replacements need to be included in the Address Replacements CSV.

To resolve this, add the sub-domain to the domain replacements as (example): source.sub-domain.com to destination.primarydomain.com

(4) A user is shared a folder on the source via one of their alias addresses which has not been replaced accordingly in address replacements.

To resolve this, add the alias address to the address replacements CSV as (example): alias@source.com to primaryaddress@destination.com.

Conclusion

Per this article, provision all users and groups in the destination and employ domain and address replacements to ensure that CloudM Migrate knows what to do with unknown addresses while performing the migration and resolving item permissions.

FAQs:

Why does it fail the migration for the user rather than skip and move on?