web-dev-qa-db-fra.com

Pourquoi un travail du planificateur de tâches ne peut-il pas accéder à un lecteur réseau mappé?

J'ai un travail de planificateur de tâches à exécuter Robocopy pour la sauvegarde de fichiers locaux sur un partage réseau. Je dois utiliser les informations d'identification du domaine pour accéder au partage réseau, mais l'ordinateur local ne se trouve pas sur le domaine et le travail est exécuté en tant qu'administrateur local. Cette solution de mapper et de démapper temporairement le partage réseau fonctionne, mais laisse mon mot de passe exposé en texte brut pour toute personne consultant les actions du job Planificateur de tâches. Je préférerais mapper le lecteur réseau normalement sur une base semi-permanente afin que le travail du Planificateur de tâches doive simplement exécuter Robocopy et se référer à la lettre de lecteur appropriée. Cependant, j'obtiens toujours l'erreur "Le système ne peut pas trouver le chemin spécifié". dans le journal Robocopy lorsque vous l'exécutez à partir du planificateur de tâches, même si la commande fonctionne correctement à partir d'une invite élevée (le travail est configuré pour s'exécuter avec les privilèges les plus élevés). Notez également que j'ai fait ce registre Tweak pour accéder à des lecteurs mappés à partir d'une invite de commande élevée.

EDIT: Pour clarifier, connecté en tant qu'administrateur local, je lance l'explorateur Windows en tant qu'administrateur. Je mappe le partage réseau sur la lettre de lecteur Y. Je lance la commande Invite en tant qu’administrateur et lance

C:\Windows\System32\Robocopy.exe C:\temp Y:\temp

Fonctionne bien. Je crée un travail de planificateur de tâches pour exécuter la même commande, que l'utilisateur soit connecté ou non, avec les privilèges les plus élevés. Je le lance et reçois une erreur. J'écris dans un journal et je reçois

ERROR 3 (0x00000003) Getting File System Type of Destination Y:\temp\
The system cannot find the path specified.

suivi par

ERROR 3 (0x00000003) Creating Destination Directory Y:\temp\
The system cannot find the path specified.
26
Craig W

Les lecteurs mappés sont un concept d'interface utilisateur et ne sont pas disponibles pour des tâches en arrière-plan de ce type. Accédez à la cible via UNC et assurez-vous que l'utilisateur sur lequel la tâche est exécutée a accès à la cible.

17
Jack

Dans mon cas, tout ce que je devais faire était de décocher l’indicateur run with highest privileges mais d’exécuter la tâche sur le même utilisateur que celui qui a mappé le lecteur.

7
Peter

Essayez d'utiliser:

pushd \\machine\share

dans un fichier batch de votre tâche planifiée. Les disques partagés en réseau ne sont disponibles que dans un environnement exécuté par l'utilisateur. "pushd" lui permettra d'être exécuté dans le contexte du script.

Lorsque vous avez terminé, utilisez:

popd \\machine\share

démapper le lecteur.

Référence: https://blog.adrianbanks.co.uk/windows/2007/03/08/accessing-network-file-shares-from-a-command-Prompt.html

3
Anthony

J'ai résolu le problème en modifiant l'option "Exécuter si l'utilisateur est connecté ou non" par "Exécuter uniquement lorsque l'utilisateur est connecté". Essayez ceci, cela peut vous aider.

1
user731960
echo Get-Date >> c:\mount_nfs_log.txt
Net Use X: \\share\folder password /user:domain\user>> c:\mount_nfs_log.txt 2>&1

La création de ce script PowerShell, la planification du travail en tant que SYSTÈME et son exécution au redémarrage m'ont permis d'utiliser des lettres de lecteur dans mes scripts, car UNC n'est pas une option en raison d'un mal de tête dû à d'autres problèmes.

1
Ryan McGrath

Une autre option consiste simplement à utiliser le chemin d'accès réseau complet, tel que Robocopy les prend en charge. Robocopy c:\temp \\ serveur\partage\temp

Ou mieux encore, exécutez la sauvegarde sur le serveur lui-même. Créez un compte administrateur de domaine uniquement pour le processus de sauvegarde. Feed robocopy le mot de passe d'un fichier texte auquel seuls les administrateurs de domaine peuvent accéder.

Il y a des années, j'ai créé plusieurs scripts .cmd qui sauvegardaient ainsi les fichiers essentiels de tous les systèmes du réseau. Le seul programme externe que j'ai utilisé était la commande Grep de Cgywin et une commande Expéditeur de messagerie smtp.

J'ai créé un script pour analyser le réseau à la recherche de systèmes. Il créerait un fichier texte de tous les noms de systèmes et me préviendrait par courrier électronique de tout nouveau système trouvé. (J'avais un fichier de configuration à analyser pour que les systèmes l'ignore.) Chaque nouveau système disposait d'un répertoire de sauvegarde créé et d'un fichier de configuration de sauvegarde placé dans celui-ci. L'utilisateur peut modifier ce fichier et répertorier tous les répertoires nécessitant une sauvegarde. Ils pourraient également spécifier l'heure de leurs sauvegardes pour que cela ne se produise pas lorsqu'ils étaient au bureau. J'ai exécuté ce script sur le serveur toutes les 5 minutes, car cela ne prenait pas de temps de traitement et j'aime bien la fonction de sécurité qui consiste à m'avertir lorsqu'un nouveau système est branché sur le réseau.

Un autre script analysera tous les fichiers de configuration de sauvegarde individuels et planifiera une tâche pour exécuter une sauvegarde sur ce système. Cela a été exécuté tous les jours à 00h01.

Enfin, le script de sauvegarde analysera le fichier de configuration qui lui a été transmis par le planificateur et, en utilisant robocopy, copiera tous les fichiers. J'avais une vérification complète des erreurs sur les fichiers de configuration car les utilisateurs les éditeraient, et je recevrais des courriels sur tous les problèmes.

Les utilisateurs pouvaient lire leurs fichiers de sauvegarde, mais ne pouvaient pas supprimer la sauvegarde. Cela offrait une certaine protection contre les dommages causés par un éventuel employé mécontent.

Probablement quelque chose de beaucoup plus élégant aurait pu être créé en .vbs ou powershell, mais je ne suis pas vraiment un programmeur. Mes classes de programmation incluaient Cobal et JCL. Je me souviens d’avoir copié les scripts quand je suis parti, mais qui sait où ils sont maintenant.

1
Kevin

Comme l'a noté un autre utilisateur, définir l'option "Exécuter si l'utilisateur est connecté ou non" sur "Exécuter uniquement lorsque l'utilisateur est connecté" semble fonctionner. Vous pouvez ensuite utiliser le chemin mappé (par exemple Z :) ou le chemin du serveur (par exemple \\ NomServeur\Chemin).

Bien sûr, si vous utilisez cette option, vous devez alors faire ce qui est écrit et vous assurer que vous vous êtes connecté au serveur en tant qu'utilisateur disposant d'un accès au lecteur correspondant. Je me souviens d’être dans une ancienne entreprise avec un certain nombre d’emplois configurés comme celui-ci. Un jour, quelqu'un "s'est déconnecté" du serveur principal des travaux, sans s'attendre à ce que cela ait un impact quelconque, car ils ne mettaient pas la machine hors service de quelque façon que ce soit ...

En outre, ces jours-ci, Windows aime effectuer de nombreux redémarrages système auto-invoqués. Utilisez donc cette solution à vos risques et périls.

0
Chris Matthews

on peut utiliser les commandes suivantes, à ajouter dans le script batch, pour exécuter le script Batch à partir de la tâche de planification Windows afin d’obtenir la copie du fichier dir sur le système local à l’aide de la tâche de planification Windows; Utilisation nette Y: "\\ xxx\xxx\xxx cd/d Y: utilisateur net/d Y:/Y

0
AshishS1

Notez également que si vous effectuez le mappage dans le script et que le mot de passe contient%, il doit être écrit %% pour que le script fonctionne à partir du planificateur de tâches, mais% à partir de l'invite de commande.

0
Tom Arleth

Essayez de changer l'emplacement "démarrer dans" en "c: \". Cela a semblé résoudre le problème pour moi, alors peut-être que le système empêchait le cmd.exe de s'exécuter à partir du répertoire\windows\system32\par défaut en tant que fonction de sécurité.

0
user364486

J'ai eu le même problème en essayant d'accéder r: /xxxfilename.txt avec un lecteur Windows mappé r:\server\share lors de l’appel d’un script depuis le planificateur de tâches Windows.

J'ai résolu en utilisant //server/share/xxxfilename.txt
Veuillez noter la barre oblique inverse convertie en barre oblique.
Maintenant, mon script bash cygwin s’exécute dans le planificateur de tâches Windows et dans le shell cygwin.
Remarque: "Utilisation nette"La commande peut accéder aux lecteurs de carte dans le shell, mais affiche Indisponible. R: lorsque je lance cette commande dans le planificateur de tâches Windows.

0
ijimenez123