Dateien von Freigabe kopieren - robocopy - 0x00000005 - Access denied

[Roemer2201]

Hallo!

Folgendes Szenario: Zwei PC's im Heimnetz, einmal Windows 8.1 Enterprise (Laptop), einmal Windows 7 Professional (Desktop), beide befinden sich in der gleichen Heimnetzgruppe (eine AD-Domäne gibt es nicht). Außerdem ist auf beiden ein lokaler Benutzeraccount mit gleichem Benutzernamen und Passwort eingerichtet, der sich jeweils in der Gruppe der lokalen Administratoren befindet. Der Zugriff auf sämtliche Freigaben von Windows 8.1 nach Windows 7 funktioniert tadellos (c$, d$, Standardfreigaben in der Heimnetzgruppe, sonstige Freigaben).

Jetzt möchte ich via robocopy Dateien und Ordner von Windows 7 nach 8.1 kopieren, mit folgendem Befehl:

robocopy \\pc.lan\d$\Ordner d:\Ordner /MIR

Dabei erhalte ich stehts:

2014/08/28 07:51:34 FEHLER 5 (0x00000005) Folgende Datei wird kopiert \\pc.lan\d$\Ordner\Unterordner1\desktop.ini

Zugriff verweigert

30 Sekunden wird gewartet...

Auch "robocopy \\pc.lan\Ordner d:\Ordner /MIR" endet mit dem gleichen Fehler.

Das Gleiche (Zugriff verweigert) passiert unter der Powershell mit Copy-Item, unter der CMD mit "copy -recurse" und wie eben genannt auch mit robocopy. Die Shell als Administrator ausführen bringt immer noch den gleichen Fehler, ein Netzlaufwerk statt dem UNC-Pfad auch. Dass die Rechte nicht stimmen kann ich ausschließen, da das Kopieren über den Windows-Explorer (via Drag and Drop) funktioniert, auch von der administrativen Freigabe d$.

Ein drittes System, ebenfalls Windows 7 (diesmal Home) befindet sich auch mit in der Heimnetzgruppe, ein identischer lokaler Account existiert auf diesem nicht. Das Kopieren von diesem PC funktioniert problemlos mit "robocopy \\pc.lan\Ordner D:\Ordner /MIR"

Könnt ihr mir helfen?

[Tiro]

Dann nehme die System-Dateien (Desktop.ini, thumbs.db etc.) vom Kopiervorgang aus. Der Parameter sollte "/xf <Dateiname(n)>" sein.

[computerjan]

Hallo Roemer2201,

ähnliche Probleme hatte ich auch einmal als ich von den $-Freigaben erfahren habe. An für sich eine richtig tolle Sache was MS da erfunden hat, nur leider gibt es wohl in einer Arbeitsgruppen/Heimnetzgruppen-Umgebung damit Probleme.

Du sagst ja der Zugriff über den Explorer auf die $-Freigabe funktioniert...Mmh komisch.

Kannst aber trotzdem mal in der Registry den Wert von LocalAccountTokenFilterPolicy anpassen. Das hat bei mir damals alle Probleme mit den $-Freigaben gelöst:

Microsoft Windows 8 Administrative Shares | Create LocalAccountTokenFilterPolicy

In deiner Fehlermeldung kann ich sehen, dass er schon einmal die Dateien im Verzeichnis auflisten kann (desktop.ini). Von daher könnte es aber nur die eine Datei sein. Schonmal ein anderes Verzeichnis/andere Freigabe mit robocopy gemirrort?

VG

computerjan

[Roemer2201]

Danke für Eure Antworten!

Ich habe mir die Berechtigungen noch einmal angeschaut und diesmal den Besitzer der Dateien mit überprüft: Von besagtem "Order" war der Besitzer "pc.lan\administrator". Ich habe das auf den eigentlichen Benutzer geändert und siehe da, es funktioniert.

Nun dachte ich, dass ich den Besitz noch einmal auf den lokalen Administrator ändere, aber es funktioniert damit immer noch... Das ist mir nicht richtig klar, aber ich nehme es als gegeben hin. Der Ordner hat schon einige Umzüge mitgemacht (Bilder von Digitalkamera), XP, Vista, Windows 7, wer weiß welcher alte Account da in den Unterordnern noch als Besitzer vergeben war.

Der Registry-Wert "LocalAccountTokenFilterPolicy" hatte ich auf dem Windows 7 bereits vor langer Zeit gesetzt, da ich dort die UAC komplett deaktiviert habe. Für die andere Richtung, falls mal etwas vom Windows 8 nach 7 gespiegelt werden soll, werde ich das im Hinterkopf behalten.

Den Schalter /XF hatte ich auch bereits ausprobiert, dann hat er zwar die desktop.ini übersprungen, jedoch hing er dann an der nächsten Datei und dies war eine richtige, die wirklich kopiert werden sollte.

Danke für den Hinweis zum Kopieren eines anderen Verzeichnisses! Das hat mich letzten Endes dazu gebracht, den Besitzer zu vergleichen.

EDIT: Habe gerade noch etwas interessantes gemerkt, was aber sicherlich nicht Ursache für den Fehler war:

Durch das Kopieren der desktop.ini ist der physische Pfad auf dem Zielsystem zwar so, wie er sein soll, z.B. "d:\test", jedoch wird im Windows Explorer "Eigene Bilder" angezeigt.

Bearbeitet 28. August 2014 von Roemer2201

[Roemer2201]

Ich habe gerade noch etwas anderes probiert, was darauf hindeutet, dass es doch nicht am Besitzer lag. Ich vermute, dass es mit dem Schalter /MIR zu tun hat, denn die robocopy-Hilfe sagt:

::

:: Hinweise:

::

Bei Verwendung von /PURGE oder /MIR für das Stammverzeichnis des Volumes

wird Robocopy veranlasst, den angeforderten Vorgang auch auf Dateien im

Verzeichnis " System Volume Information" anzuwenden. Wenn dies nicht

beabsichtigt ist, kann Robocopy mit dem Schalter "/XD" veranlasst werden,

dieses Verzeichnis zu überspringen.

Ich kann mit diesem Hinweis bloß keinen Zusammenhang zu meinem Kopiervorgang herstellen. Ist mit Stammverzeichnis das Quellverzeichnis gemeint?

[paperdoll]

Nein damit ist das Verzeichnis "System Volume Information" gemeint.

Dein Problem liegt vermutlich an exclusiven Benutzerberechtigungen welche zB. in Profilen bzw. umgeleiteten Pfaden verwendet werden. Die Lösung dafür hast du mit der Besitzübernahme und entspr. korrektur der NTFS Berechtigungen ja schon gefunden.

Problematisch wirds allerdings wenn du tatsächlich Ordner umgeleitet hast, dann funktionieren im Anschluss die Umleitungen vermutlich nicht mehr - sofern hier exclusive Rechte erwartet werden.

Gruß

paper

[tester2k5]

Teste mal den Kopiervorgang ohne Datei-Attribute ("/COPY:DT"), sowie den Parameter "/FFT" (2 Sekunden Genauigkeitsdifferenz).

Gruss,

tester2k5