bodennebel
Goto Top

Robocopy - FEHLER 1 (0x00000001) Zugriff auf Zielverzeichnis . Unzulässige Funktion

Hallo zusammen,

mich plagt seit einigen Tagen ein Kopierproblem mit robocopy. Ich versuche die Ordner einer Netzwerkfreigabe von einem QNAP NAS (TS-253 Pro, QTS 4.3.3) auf unseren Windows Fileserver zu kopieren (Windows Server 2016 Standard in Hyper-V). Einen Teil der Daten kopiert er, bei einigen schreibt er den "FEHLER 1 (0x00000001) Zugriff auf Zielverzeichnis (z.B. \\Win-FS\Folder_001\Subfolder1\Subfolder2\) Unzulässige Funktion." in die Log-Datei.

Die betroffenen Verzeichnisse inklusive darunter liegender Inhalte werden auch nicht kopiert. Es betrifft nicht nur Ordner der obersten Ebene, sondern auch Unterordner, d.h. die darüberliegende Ordnerstruktur wird inklusive einiger Unterordner/Dateien teilweise kopiert.

Der verwendete Befehl sieht so aus:

robocopy "\\QNAP-NAS\Folder_001" "\\WIN-FS\Folder_001" /V /FP /TEE /E /DCOPY:DA /COPY:DAT /MIR /ZB /XJ /R:2 /W:5 /UNICODE /UNILOG:C:\Users\username\Documents\Logs\robocopy-log.txt /XD "@Recycle" /NP  

Die Pfade des Start- und Zielverzeichnisses habe ich ursprünglich nicht in Anführungszeichen gesetzt, am Kopierverhalten hat sich dadurch aber nichts geändert.

Ich starte den Befehl in der Powershell des Windows Fileservers.

Im Augenblick bin ich mit meinem Latein am Ende. Im Netz habe zu dem "Fehler 1" nichts Hilfreiches gefunden und setze daher auf eure Unterstützung.


Besten Dank

Bodennebel

Content-ID: 339875

Url: https://administrator.de/contentid/339875

Ausgedruckt am: 25.11.2024 um 03:11 Uhr

BassFishFox
BassFishFox 06.06.2017 aktualisiert um 21:36:06 Uhr
Goto Top
Hallo,

Verdammt viele Optionen die Du Deinem robocopy reinwuergst. face-wink
Schau mal in den Hilfen zu robocopy nach, was sich gegenseitig ersetzt/ergaenzt/ausschliesst. Macht am Ende halt die Zeile kuerzer. face-wink

robocopy "\\QNAP-NAS\Folder_001" "\\WIN-FS\Folder_001

Steuerst Du das Ganze von einem PC? Zugriffsrechte ausreichend fuer das Kopieren bei Quelle UND Ziel?

Ich persoenlich, wuerde den "WIN-FS" per robocopy die Daten holen lassen.

So. Zu guter Letzt.
Ist irgendein Laufwerk von Dir zufaellig ein FAT**-formatiertes Laufwerk?

BFF
114685
114685 06.06.2017 aktualisiert um 22:38:18 Uhr
Goto Top
Hi,

dass die max. Pfadlänge (32767 bei UNC-Pfaden) überschitten wird, halte ich für eher unwahrscheinlich, aber möglich ist natürlich alles.

ERROR_INVALID_FUNCTION (0x00000001) deutet eher auf einen Fehler beim Schreiben.

Ich persoenlich, wuerde den "WIN-FS" per robocopy die Daten holen lassen.

Gute Idee , Versuch macht kluch face-smile Aber ob das was bringt, wenn da tatsächlich ein Fehler beim Schreiben auftreten sollte?

Gruß
BassFishFox
BassFishFox 07.06.2017 aktualisiert um 16:24:29 Uhr
Goto Top
Hallo,

In Ergaenzung was schon geschrieben wurde.

/XD "@Recycle"

Heisst Dein Papierkorb wirklich so? Oder ist es eher so?

/XD $Recycle.bin

Zusaetzlich schau mal nach, ob Du in der Quelle die System Volume Information hast. Diese auch ausschliessen.
Wir benutzen u.A. diesen Eintrag.

/XD $Recycle.bin Recycler "System Volume Information"

Und bring das /XD mal vor das Logging.

BFF
BassFishFox
BassFishFox 07.06.2017 um 15:33:59 Uhr
Goto Top
Hallo,

dass die max. Pfadlänge (32767 bei UNC-Pfaden) überschitten wird

Darum gehts mir nicht.

Wir hatten mal vor langer Zeit Probleme beim Einsammeln von Daten mittels robocopy, wenn die Quelle zufaellig ein FAT32-LW war. Dann tauchte ab und zu extakt der selbe Fehler im Protokoll auf. Ebenso, kann dieser Fehler auftauchen, wenn die Quelle nicht NTFS ist und in den Ordnern mit einem anderen OS wie Windows z.B. Symlinks erzeugt oder Rechte an Dateien veraendert wurden. Das bringt dann wieder Deine Vermutung

deutet eher auf einen Fehler beim Schreiben.

ins Spiel.

Wie dem auch sei, lassen wir @Bodennebel erstmal wieder antworten. face-smile

BFF
114685
114685 07.06.2017 um 15:51:06 Uhr
Goto Top
Hi,

Zustimmung.
Das mit den SYMLINKS hatte ich auch im Hinterkopf, bis ich gesehen habe, dass er die ja ausgeklammert hat. (/XJ), dann habe ich das schnell wieder gelöscht. face-smile

Die Fehlermeldung 1 wird seit Urzeiten meist von IOCTRL bzw jetzt DeviceIoControl erzeugt, insofern würde es passen.

Gruß
Bodennebel
Bodennebel 07.06.2017 um 20:15:59 Uhr
Goto Top
Hallo BFF,

danke für Dein Feedback. Ich versuche mal Deine und hugonatters Fragen und Anmerkungen an den entsprechenden Stellen zu kommentieren bzw. zu beantworten und hoffe, dass kein Chaos entsteht.

Zitat von @BassFishFox:

Verdammt viele Optionen die Du Deinem robocopy reinwuergst. face-wink
Schau mal in den Hilfen zu robocopy nach, was sich gegenseitig ersetzt/ergaenzt/ausschliesst. Macht am Ende halt die Zeile kuerzer. face-wink

Gut, da hast Du natürlich recht, /COPY:DAT (Standardvorgabe) und /E (wegen /MIR) kann ich mir eigentlich schenken.


robocopy "\\QNAP-NAS\Folder_001" "\\WIN-FS\Folder_001

Steuerst Du das Ganze von einem PC? Zugriffsrechte ausreichend fuer das Kopieren bei Quelle UND Ziel?


Ja, das ganze wird mit einem Benutzer durchgeführt, der Vollzugriff auf WIN-FS (Ziel) hat. Auf der Quelle (QNAP-NAS) ist der gleiche Benutzer mit R/W-Rechten versehen. Man kann auf dem QNAP-NAS Benutzern nur Read-Only, Deny oder R/W verpassen. Beim Benutzer handelt es sich um einen AD-Account, keinen lokalen User.

Ich persoenlich, wuerde den "WIN-FS" per robocopy die Daten holen lassen.


Der Befehl wird mit dem entsprechenden User von WIN-FS aus abgeschickt. Ich habe den Befehl über cmd und Powershell im Administrator-Mode abgesetzt, das machte aber keinen Unterschied. Oder habe ich Dich hier missverstanden?

So. Zu guter Letzt.
Ist irgendein Laufwerk von Dir zufaellig ein FAT**-formatiertes Laufwerk?


Das QNAP-NAS hat meines Wissens EXT4 als Filesystem und das Zielsystem WIN-FS ist NTFS formatiert.

BFF
Bodennebel
Bodennebel 07.06.2017 um 20:27:36 Uhr
Goto Top
Zitat von @BassFishFox:

Hallo,

In Ergaenzung was schon geschrieben wurde.

/XD "@Recycle"

Heisst Dein Papierkorb wirklich so? Oder ist es eher so?

/XD $Recycle.bin


Ja, der heisst tatsächlich so und ist ein Netzwerkpapierkorb auf dem QNAP-NAS.

Zusaetzlich schau mal nach, ob Du in der Quelle die System Volume Information hast. Diese auch ausschliessen.
Wir benutzen u.A. diesen Eintrag.

/XD $Recycle.bin Recycler "System Volume Information"


QTS ist ein Linux-Derivat, da gibt es die System Volume Information meines Wissens nicht.

Und bring das /XD mal vor das Logging.


Das Ausschliessen des "@Recycle" Ordners funktioniert an der von mir angegebenen Stelle ganz wunderbar. Ich habe aber Deinen Vorschlag ausprobiert, leider ohne Erfolg.

BFF
Bodennebel
Bodennebel 07.06.2017 um 20:45:15 Uhr
Goto Top
Hallo hugonatter,

auch Dir vielen Dank für die Hilfe bei der Fehlersuche.

Zitat von @114685:

Hi,

Zustimmung.
Das mit den SYMLINKS hatte ich auch im Hinterkopf, bis ich gesehen habe, dass er die ja ausgeklammert hat. (/XJ), dann habe ich das schnell wieder gelöscht. face-smile


/XJ hatte ich mal im Rahmen einer Kopieraktion eines Windows-Systemlaufwerks entdeckt. Ist da sehr praktisch face-smile

Die Fehlermeldung 1 wird seit Urzeiten meist von IOCTRL bzw jetzt DeviceIoControl erzeugt, insofern würde es passen.

Gruß
Bodennebel
Bodennebel 07.06.2017 um 21:06:15 Uhr
Goto Top
Kleiner Nachtrag zu den Rechten: Habe mir in der Filestation 5 (Filemanager auf dem QNAP-NAS) die Eigentümer- und Gruppenrechte der widerspenstigen Ordner und erfolgreich kopierter angesehen und verglichen: Die waren alle identisch und entsprechen chmod 777.
BassFishFox
BassFishFox 07.06.2017 um 22:45:54 Uhr
Goto Top
Hallo,

Das Ausschliessen des "@Recycle" Ordners funktioniert an der von mir angegebenen Stelle ganz wunderbar. Ich habe aber Deinen Vorschlag ausprobiert, leider ohne Erfolg.

Wenn der Papierkorb so heisst, kann er auch so ausgeschlossen werden. face-wink

robocopy "\\QNAP-NAS\Folder_001" "\\WIN-FS\Folder_001"
Oder habe ich Dich hier missverstanden?

Wenn der Server die Daten selbst holt ist es ok. Ist halt etwas ungewoehnlich den Server in seine eigenes Share schreiben zu lassen, anstatt auf sein Laufwerk. Sah fuer mich so aus, dass von einem PC aus robocopy eingesetzt wird umd von extern A nach extern B Daten zu schaufeln.

Die waren alle identisch und entsprechen chmod 777.

Was sagt eigentlich das eventlog des Servers zu den "widerspenstigen Dateien"?

BFF
Bodennebel
Bodennebel 08.06.2017 um 21:35:55 Uhr
Goto Top
Hallo BFF,

Zitat von @BassFishFox:

Wenn der Server die Daten selbst holt ist es ok. Ist halt etwas ungewoehnlich den Server in seine eigenes Share schreiben zu lassen, anstatt auf sein Laufwerk. Sah fuer mich so aus, dass von einem PC aus robocopy eingesetzt wird umd von extern A nach extern B Daten zu schaufeln.


ich habe testweise das Ziel-Share \\WIN-FS\Folder_001 durch den Laufwerkspfad D:\Folder_001 ersetzt. Brachte aber keine Besserung face-sad

Was sagt eigentlich das eventlog des Servers zu den "widerspenstigen Dateien"?

In der Ereignisanzeige konnte ich nichts finden. Ich will aber nicht ausschließen, dass ich an den falschen Stellen gesucht habe.

Gruß
Bodennebel
BassFishFox
BassFishFox 08.06.2017 um 21:47:01 Uhr
Goto Top
Hallo,

Hast Du mal versucht, per Dateiexplorer auf dem Server, die betreffenden Dateien/Ordner zu kopieren?

Irgendwas muss an den Quelldaten schief gewickelt sein.

BFF
Bodennebel
Bodennebel 08.06.2017 um 23:34:04 Uhr
Goto Top
Hi,

ich habe jetzt den Spieß mal umgedreht und vom QNAP aus eine Kopieraktion auf das Windows-Share angestoßen. Bisher hat er den Kopierjob erst einmal abgebrochen weil ihm ein Dateiname nicht gefiel. Ich glaube, er hatte sich an den doppelten Anführungszeichen im Dateinamen gestört. Nachdem ich diese aus dem Dateinamen gelöscht hatte lief er fröhlich weiter. Mal schauen was das Protokoll morgen sagt.

BN
BassFishFox
BassFishFox 08.06.2017 aktualisiert um 23:54:00 Uhr
Goto Top
Hallo,

Ich glaube, er hatte sich an den doppelten Anführungszeichen im Dateinamen gestört

Das waere meine naechste Frage gewesen. Irgendwelche " ' ` ~ im Dateinamen? face-big-smile

BFF