Déploiement de KB : Le proxy Datadobi DobiMigrate n’a pas accès aux partages/exportations sources

Au cours de la première copie et des deux itérations suivantes de problèmes d’accès refusé sur les fichiers et les répertoires, beaucoup d’entre eux sont récurrents.

Un comportement étrange est que le même fichier peut être copié lors d’une itération, mais que l’itération suivante signale des erreurs d’accès refusé dans les journaux.

Le même chemin est vérifié à chaque fois et de manière aléatoire, les fichiers signalent un accès refusé, et les mêmes fichiers ne sont pas signalés dans les itérations suivantes, puis font un rapport.

Par exemple :

Pour les répertoires :

error: AccessDeniedException: /IT/transcore/src2/org
error: AccessDeniedException: /IT/transcore/src

Après la remigration, se transforme en :

DirectoryIteratorException: java.nio.file.AccessDeniedException: /IT/transcore/src2
DirectoryIteratorException: java.nio.file.AccessDeniedException: /IT/transcore/src

• Lorsque vous comparez la source et la destination, vous constatez que le répertoire n’a pas été copié vers la cible.
• Essayez de cliquer dessus et de remigrer les métadonnées de force + copie de données, ou essayez de démarrer une autre itération avec les métadonnées de recopie, le résultat est un échec
• Si vous essayez de comparer toutes les autorisations du côté NFS et CIFS, les deux ont exactement les mêmes autorisations, le répertoire parent /IT/transcore et le sous-répertoire IT/transcore/src2.

Pour le fichier :

AccessDeniedException: /Marketing/fvb_test/SCR.pdf

• En comparant la source et la destination, vous constaterez peut-être que le fichier PDF est copié, qu’il a la même autorisation, la même taille et que tout est exactement le même, à l’exception du propriétaire qui est un utilisateur root de Linux alors que dans la source, il s’agissait d’un utilisateur normal.
• Essayez d’ouvrir le fichier sur la destination, il se peut qu’il soit corrompu et qu’il ne s’ouvre pas comme la source, ce qui est tout à fait normal.
• Essayez de remigrer les métadonnées, mais cela n’a pas fonctionné.
• Toutefois, après avoir poussé une itération normale sur le chemin total 2 ou 3 fois, vous pouvez constater que cette erreur pour ce fichier spécifique n’est pas récurrente et que sur la baie de destination, il s’ouvre normalement et fonctionne correctement.

La cause du problème était que l’un des proxys NFS se trouvait sur un autre réseau et n’était pas en mesure d’explorer les données sources. Il n’y avait pas accès.

Suppression de l’exportation NFS qui se trouvait sur un autre réseau et qui n’avait pas d’accès.

Afin d’identifier quel proxy NFS a ou n’a pas accès.

Accédez à Datadobi Management UI (Core) > Tools File Browser > Sélectionner le stockage > Sélectionnez le proxy > Explore the Files et assurez-vous que vous pouvez accéder à tous les fichiers à l’aide de > ce proxy.

Procédez comme ci-dessus en utilisant tous les proxys pour identifier quel fichier n’a pas accès, puis vous pourrez confirmer si les proxys ont accès ou non.