SourceOne for Files Systems: Users cannot retrieve files with "My Files" permissions

SourceOne for Files Systems: Users cannot retrieve files with the mapped folder "My Files" permissions assigned to the Domain users AD group.
Although if using the service account identity, all file shortcuts can be accessed. However all standard users cannot access any files, unless their access permissions are directly specified under the NTFS permissions on the file itself before the file is archived and shortcut ( using the snapshot of file system permissions).

After a failure to retrieve you will see the following in the Docmanageservice log:
DocumentService::DoGetMessage|ERROR|GetMessage error: Error Code: 0x80070005, Folder: xxxxxxxx Access is denied. (Exception from HRESULT: 0x80070005 (E_ACCESSDENIED)) |(0)|Job Id: -1; Activity Name: SERV1551; Activity Id: -1; Activity Type: -1; Servername

Dell EMC have a Test-Group tool, former TestFixForGetAuthorizedGroup.  That uses the same classes as the SourceOne application to establish if the service account can read the AD groups where the users resides.
This tool uses System.DirectoryServices Namespace classes to find the AD users, e.g:
var domain = new PrincipalContext(ContextType.Domain);
var user = UserPrincipal.FindByIdentity(domain, userName);
UserPrincipal upLogonUser = UserPrincipal.FindByIdentity(pc, IdentityType.DistinguishedName, sUserDN);

Unless this tool runs under a Domain administrator Identity, you will get the following exception:

************** Exception Text **************
System.Runtime.InteropServices.COMException (0x8007200A): The specified directory service attribute or value does not exist.
at System.DirectoryServices.DirectoryEntry.Bind(Boolean throwIfFail)
at System.DirectoryServices.DirectoryEntry.Bind()
at System.DirectoryServices.DirectoryEntry.get_SchemaEntry()
at System.DirectoryServices.AccountManagement.ADStoreCtx.IsContainer(DirectoryEntry de)
at System.DirectoryServices.AccountManagement.ADStoreCtx..ctor(DirectoryEntry ctxBase, Boolean ownCtxBase, String username, String password, ContextOptions options)
at System.DirectoryServices.AccountManagement.PrincipalContext.CreateContextFromDirectoryEntry(DirectoryEntry entry)
at System.DirectoryServices.AccountManagement.PrincipalContext.DoLDAPDirectoryInitNoContainer()
at System.DirectoryServices.AccountManagement.PrincipalContext.DoDomainInit()
at System.DirectoryServices.AccountManagement.PrincipalContext.Initialize()
at System.DirectoryServices.AccountManagement.PrincipalContext.get_QueryCtx()
at System.DirectoryServices.AccountManagement.Principal.FindByIdentityWithTypeHelper(PrincipalContext context, Type principalType, Nullable`1 identityType, String identityValue, DateTime refDate)
at System.DirectoryServices.AccountManagement.Principal.FindByIdentityWithType(PrincipalContext context, Type principalType, String identityValue)
at System.DirectoryServices.AccountManagement.UserPrincipal.FindByIdentity(PrincipalContext context, String identityValue)
at TestFixForGetAuthorizedGroup.Form1.GetUserDistinguishedName(String userName)
at TestFixForGetAuthorizedGroup.Form1.GetUserGroups_Click(Object sender, EventArgs e)

Also, running this basic PS1 script that invoke s the same classes return the same "The specified directory service attribute or value does not exist.": error:

$userName =  Service account            
Add-Type -AssemblyName System.DirectoryServices.AccountManagement           
$ct = [System.DirectoryServices.AccountManagement.ContextType]::Domain           
$user = [System.DirectoryServices.AccountManagement.Principal]::FindByIdentity($ct,$userName)           
$user.GetGroups() #gets all user groups (direct)           
$user.GetAuthorizationGroups() #gets all user groups including nested groups (indirect)

https://blogs.msdn.microsoft.com/dsadsi/2009/08/28/getting-an-exception-the-specified-directory-service-attribute-or-value-does-not-exist-when-you-try-to-search-a-user-in-an-ad-container-using-system-directoryservices-accountmanagement/

"Getting an exception  The specified directory service attribute or value does not exist , when you try to search a user in an AD container using System.DirectoryServices.AccountManagement.UserPrincipal::FindByIdentity

This happens because If there is no container  specified, the principal context class will create a System.DirectoryServices.DirectoryEntry object by binding to builtin CN=Users container to start searching for users. System.DirectoryServices is built on top of ADSI.  ADSI by default does an objectclass=* search as part of its normal bind process unless the fastbind flag is specified.  if the user  performing the search does not  have permission to read the attributes of default users contain, the search operation will fail, thus causing  The specified directory service attribute or value does not exist , exception.

This is also true when searching computer objects using ComputerPrincipal::FindByIdentity and you don t have read permission on CN=Computer container and have not specified a container in the constructor of System.DirectoryServices.AccountManagemnt.PrincipalContext. The remarks section of the documentation at http://msdn.microsoft.com/en-us/library/system.directoryservices.accountmanagement.principalcontext.principalcontext.aspx explains the rules followed by the PrincipalContext class in selecting a container when one has not been explicitly specified in the constructor."

Assign read permission on AD groups.