Windows-Aufgabenplanung => YARCGUI / Robocopy => Zielordner existiert nicht

[Donatello]

Hallo Computerbase-Gemeinde,
ich verwende seit ca. 2 Jahren Robocopy mit YARCGUI auf unseren Familienrechnern und im Freundeskreis.
YARCGUI wird einmal täglich kurz nach dem ersten Rechnerstart durch die Windows Aufgabenplanung automatisch gestartet.
In allen Familien-Netzwerken läuft ein Synology NAS als File-Server.

Einige Dateien und Ordner (z. B. Browser-Lesezeichen, Calibre-Bibliothek etc.) werden mit YARCGUI nach einem Zeitschema (einmal täglich zu einer bestimmten Uhrzeit) vom jeweiligen Rechner auf das NAS oder umgekehrt kopiert.
Die Möglichkeiten von YARCGUI/Robocopy in Verbindung mit der Windows Aufgabenplanung sind also ideal für unsere Bedürfnisse.

PROBLEM-BESCHREIBUNG:
Seit einigen Monaten werden die Robocopy-Aufträge auf 4 von 5 Rechnern nicht mehr gestartet. Die Windows Aufgabenplanung startet zwar YARCGUI, aber YARCGUI meldet dann im Protokoll folgendes:
08:16:39 Zielordner "\\NAS-Name\Music\Playlists" existiert nicht und konnte nicht angelegt werden!
08:16:39 Auftragsvalidierung fehlgeschlagen.
08:16:39 Robocopyauftrag kann nicht gestartet werden!

Das deutet für mich zunächst auf ein Netzwerkproblem hin. ALLERDINGS tritt dieses Problem nur dann auf, wenn YARCGUI das erste Mal am Tag durch die Windows-Aufgabenplanung gestartet wird.
Starte ich die Jobs stattdessen direkt in YARCGUI, laufen sie immer fehlerfrei.
Auch kann ich unmittelbar nach Rechnerstart über den Windows-Explorer auf das NAS zugreifen. Also liegt praktisch betrachtet gar kein Netzwerkproblem vor!

Wenn ich die Jobs direkt in YARCGUI laufen lasse und danach in der W-Aufgabenplanung den Timer entsprechend vorstelle, wird danach die Sicherung automatisch gestartet und läuft dann immer komplett fehlerfrei. Am nächsten Tag tritt dann wieder das beschriebene Problem auf.

?? Hat jemand eine Idee für uns, wie wir das Problem beheben können ??

Beste Grüße
Donatello

 

[Rickmer]

08:16:39 Zielordner "\\NAS-Name\Music\Playlists" existiert nicht und konnte nicht angelegt werden!

Dem musst du die Credentials im Skript mitliefern*
Das läuft nicht in deiner User-Session, daher können für deine User-Session hinterlegte Credentials nicht abgerufen werden

(Denke ich. Ich hatte mal ähnliche Probleme weil ich nicht wusste, dass Laufwerksmappings in solch einem Fall auch nicht vorhanden sind.
Zumindest gehe ich davon aus, dass du privat kein Active Directory o.Ä. laufen hast, welches dir erlauben würde, mit dem Windows-User direkt auf das NAS zuzugreifen.)


*niemals Passwörter im Skript selber ablegen das ist unsicher und daher eine schlechte Angewohnheit, auch im privaten Netzwerk. Ein Credentials-Objekt anlegen und dieses mit deinem Skript aufrufen.

 

[Donatello]

@Rickmer:
DANKE für Deine schnelle Reaktion!!

Active Directory habe ich nicht laufen. Hast Du richtig erkannt

Um Deinen Tipp

Credentials im Skript mitliefern

und

Ein Credentials-Objekt anlegen und dieses mit deinem Skript aufrufen

"zu verstehen, fehlt mir offenbar leider das Wissen. Kannst Du da konkreter werden, damit ich verstehe, was genau ich machen muss?

Laufwerksmapping verwende ich in meinen Skripten nicht. Das Ziellaufwerk beginnt immer mit \\Servername\Zielverzeichnis..., nicht mit einem gemappten Laufwerksbuchstaben.

Passwörter verwende ich nicht in den Skripten der YARCGUI-Jobs. Ich habe mir nie Gedanken darüber machen müssen, weil ja die Sicherungen bis vor wenigen Monaten immer anstandslos liefen.

 

[Rickmer]

Passwörter verwende ich nicht in den Skripten der YARCGUI-Jobs. Ich habe mir nie Gedanken darüber machen müssen, weil ja die Sicherungen bis vor wenigen Monaten immer anstandslos liefen.

Du wirst ja für den Zugriff auf das Netzlaufwerk am NAS ein Passwort brauchen, oder?
Das hast du sicherlich vor Monaten/Jahren mal am PC eingetippt, den Haken für 'Passwort merken' angeklickt und dir keine weiteren Gedanken drüber gemacht.

Die gespeicherten Anmeldedaten sind in Systemsteuerung -> Anmeldeinformationsverwaltung zu finden.

Kannst Du da konkreter werden, damit ich verstehe, was genau ich machen muss?

Siehe hier:
https://klyavlin.wordpress.com/2012/09/19/robocopy-network-usernamepassword/

Da wird dasallerdings gezeigt mit Passwort im Skript im Klartext abgelegt. Kann man privat machen, ist aber nicht empfehlenswert.

Wie rufst du Robocopy auf? Direkt über die Aufgabenplanung, per Batch-Skript, oder noch anders?
Auswendig kenne ich das richtige Handhaben von Credentials nur für Powershell, sonst müsstest du halt selber mal schauen.

 

[Donatello]

Bei mir wird durch die Aufgabenplanung YARCGUI aufgerufen (und damit wohl im Hintergrund auch Robocopy).

Du hast Recht: die Anmeldedaten für den NAS-Zugriff sind in der Anmeldeinformationsverwaltung definiert. Damit entfällt auch, dass ich mich jedes Mal doppelt anmelden muss: beim Booten auf dem Rechner und dann beim NAS-Zugriff auf dem NAS. Durch den Rechnerstart bin ich also quasi automatisch auch auf dem NAS angemeldet. Mir ist allerdings nicht klar, dass diese Art das Passwort im Skript im Klartext bereitstellt.
Aber man lernt ja nie aus.
Deinen Link auf klyavlin schaue ich mir gleich nach dem Abendessen an. Bin gespannt. Melde mich danach!

 

[Donatello]

Ich habe mir die Beschreibung auf der klyavlin-Homepage angeschaut. Hat mir aber leider nicht weitergeholfen. Ich finde da überhaupt keinen Zugang zu einer Lösung.
Ich sehe den Zusammenhang zwischen der dortigen Beschreibung und meinem Problem nicht, denn der in meiner Win-Aufgabenplanung definierte Job ist zum Zeitpunkt des Aufrufes bereits am betroffenen Rechner UND am NAS angemeldet => In der Aufgabenplanung Tab "Allgemein" unter "Sicherheitsoptionen" ist mein aktives (Admin-)Benutzerkonto eingetragen mit dem Zusatz "Mit höchsten Berechtigungen ausführen".
Bemerkenswert ist ja, dass ein anderer Win 10-Rechner in unserem Haus mit exakt den gleichen Einstellungen fehlerfrei sichert.
Ich bin nach wie vor ratlos ... Aber besten Dank, Rickmer, dass du dir Zeit für mich genommen hast.

Hat sonst noch jemand eine Idee, was der Grund für das Problem sein könnte?

 

[Rickmer]

Hmm... ich kenne mich nicht gut genug aus mit dem Credentials-Speicher und wann das Skript da was abrufen können sollte...

Eventuell müsstest du mal schauen, ob du auf der NAS im Logging feststellen kannst, ob zum Zeitpunkt des Ausführen des Skript ein Zugriffsversuch war.

 

[Donatello]

OK. Das mache ich morgen Vormittag. Werde berichten. DANKE, dass Du dich nochmal gemeldet hast

 

[Donatello]

... du mal schauen, ob du auf der NAS im Logging feststellen kannst, ob zum Zeitpunkt des Ausführen des Skript ein Zugriffsversuch war...

Ich habe auf der Synology das Protokoll-Center für die Rubrik "Verbindung" geprüft:
Für den Zeitpunkt des Ausführens des Sicherungsskriptes gibt es hier KEINEN Eintrag.
=> Weder für den Rechner meiner Frau (auf der die Sicherung gelaufen ist)
=> noch für meinen Rechner
Im Protokoll gelistet sind nur die Verbindungen, die beim Hochfahren unserer Rechner entstehen (vermutlich, weil sich die Rechner beim Booten ja durch den Eintrag in den Windows-Anmeldeinformationen auf dem NAS automatisch anmelden)

Weshalb auf dem Rechner meiner Frau die Sicherung momentan wieder läuft, kann ich nicht erklären.
Ich habe auf dort dem Standard-User die Admin-Rechte weggenommen und stattdessen einen neuen Admin-User angelegt. Danach habe ich in der Windows-Auftragsverwaltung die Aufgabe neu erstellt mit dem Unterschied, dass der Autor jetzt der neue Admin ist und beim Ausführen der Aufgabe das Standard-Benutzerkonto verwendet werden soll (siehe Grafik)

 

[Donatello]

!! GELÖST !!
Ich habe nun folgende Punkte bearbeitet:
1) Passworte in der Windows-Anmeldeinformationsverwaltung für den NAS-Zugriff neu eingetragen
2) YARCGUI-Verzeichnis verschoben, so dass im Pfad keine Leerzeichen mehr vorkommen (habe ich irgendwo als Tipp gelesen). Die Pfadeinträge in den YARCGUI-Jobs habe ich natürlich entsprechend korrigiert.
3) Außerdem habe ich in der Windows-Aufgabenplanung in der Job-Definition im Reiter "Einstellungen" das Häkchen "Ausführung bei Bedarf zulassen" enabled.

Irgendwo in diesen drei Punkten oder einem Mix daraus lag wohl der Grund für die Probleme, denn heute morgen liefen auf allen Rechner die Sicherungen fehlerfrei.
Das Prohlem scheint also gelöst.

Danke, an alle, die sich mit meiner Frage beschäftigt haben!
Beste Grüße
Donatello

 

[Rickmer]

Danke für die Rückmeldung - es freut mich, dass es jetzt doch noch klappt.