Que peut-on faire pour vous aider aujourd'hui?
Outil de test de partage de fichiers
MyWorkDrive dispose d'un outil de test intégré pour vous permettre de tester si un utilisateur a accès à un partage ou à un fichier. L'outil signalera le succès ou l'échec et donnera des détails pour guider la résolution du problème. Cela montrera si des problèmes d'autorisation empêchent un utilisateur d'accéder à un partage, un dossier ou un fichier. Ceci est un autre bon test à exécuter si un utilisateur signale qu'il ne peut pas ouvrir quelconque fichiers dans un partage ou un dossier particulier.
L'outil de test est disponible dans la version 5.4.1 et ultérieure du serveur.
Dans l'onglet Partages du panneau d'administration, sélectionnez le partage que vous souhaitez tester (cliquez simplement sur le nom du partage pour mettre la ligne en surbrillance), puis cliquez sur Tester dans la ligne ci-dessus.
Sur l'écran de test, vous pouvez entrer un dossier spécifique ou même un fichier spécifique si vous le souhaitez. Ou testez simplement la racine du partage. Le sous-dossier/fichier en surbrillance est facultatif. Si un utilisateur signale ne pas obtenir de partage lors de la connexion, laissez ce champ vide.
Utilisez ensuite User/Pass avec les informations d'identification de l'utilisateur ou passez en SSO et entrez l'e-mail de l'utilisateur (si vous utilisez Connexions SSO et ont délégation configurée) pour tester les droits d'accès à MyWorkDrive.
Si vous spécifiez le nom d'utilisateur, vous devrez spécifier le domaine de l'utilisateur. Le format préférable est domaine\utilisateur, comme illustré dans cet exemple.
Le test indiquera si le serveur MyWorkDrive peut ou non accéder au partage ou au fichier/dossier. Dans cet exemple, l'utilisateur a accès à l'emplacement de test, car l'outil de test signale que l'utilisateur (nom d'utilisateur) a accès au partage…
Voici un exemple d'échec d'un test. Dans ce cas, l'utilisateur n'est pas autorisé à écrire sur le partage.
Si l'utilisateur n'a PAS accès au partage, vérifiez vos paramètres d'autorisation dans NTFS, les appartenances aux groupes d'utilisateurs ou utilisez l'outil d'accès effectif dans Windows pour un dépannage plus approfondi.
Erreur des outils RSAT
Remarque, si la réponse indique que les outils RSAT ne sont pas disponibles
"Les outils PowerShell RSAT ne sont pas installés sur ce serveur. Veuillez installer les outils Active Directory RSAT pour exécuter l'outil de test.
Vous pouvez utiliser Powershell pour installer les fonctionnalités RSAT sur le serveur 2016/2019
Installer-WindowsFeature -IncludeAllSubFeature RSAT
pour des options/alternatives d'installation supplémentaires, voir
https://www.ntweekly.com/2017/07/04/install-all-rsat-tools-in-one-single-cmdlet-on-windows-server-2016/
https://docs.microsoft.com/en-us/powershell/module/servermanager/install-windowsfeature?view=winserver2012r2-ps
Notez que l'installation peut nécessiter un redémarrage du serveur.
Validation avec accès effectif
Parfois, le problème est un conflit entre NTFS et les autorisations de partage, ce qui entraîne le blocage des autorisations d'écriture via MyWorkDrive. Vous pouvez tester cela en utilisant Effective Access. Ce test montrera si la configuration du partage de fichiers est la cause de votre problème d'ouverture de fichiers. Cela se présente généralement comme un utilisateur incapable de modifier des fichiers dans un dossier ou un répertoire entier.
Accédez au partage sur le serveur MyWorkDrive et faites un clic droit dessus. De la sécurité | avancé choisissez Accès effectif, puis choisissez l'utilisateur comme principal et cliquez sur afficher.
Cela vous indiquera quel est l'accès effectif et si cet utilisateur peut accéder au partage sur le serveur MyWorkDrive.
S'il y a un X rouge à côté des autorisations d'écriture, l'utilisateur sera (correctement) informé que le fichier est en lecture seule car MyWorkDrive ne pourra pas l'écrire avec ses informations d'identification. Les autorisations sur le fichier/dossier/partage doivent être corrigées.
Dans cet exemple, vous pouvez voir que les autorisations de partage (et non NTFS) ont empêché cet utilisateur d'avoir un accès en écriture à ce dossier.
