14
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:
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
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
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 339875
Url: https://administrator.de/contentid/339875
Printed on: April 27, 2024 at 17:04 o'clock
14 Comments
Latest comment
Hallo,
Verdammt viele Optionen die Du Deinem robocopy reinwuergst.
Schau mal in den Hilfen zu robocopy nach, was sich gegenseitig ersetzt/ergaenzt/ausschliesst. Macht am Ende halt die Zeile kuerzer.
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
Verdammt viele Optionen die Du Deinem robocopy reinwuergst.
Schau mal in den Hilfen zu robocopy nach, was sich gegenseitig ersetzt/ergaenzt/ausschliesst. Macht am Ende halt die Zeile kuerzer.
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
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.
Gute Idee , Versuch macht kluch
Aber ob das was bringt, wenn da tatsächlich ein Fehler beim Schreiben auftreten sollte?
Gruß
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
Aber ob das was bringt, wenn da tatsächlich ein Fehler beim Schreiben auftreten sollte?Gruß
Hallo,
In Ergaenzung was schon geschrieben wurde.
Heisst Dein Papierkorb wirklich so? Oder ist es eher so?
Zusaetzlich schau mal nach, ob Du in der Quelle die System Volume Information hast. Diese auch ausschliessen.
Wir benutzen u.A. diesen Eintrag.
Und bring das /XD mal vor das Logging.
BFF
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
Hallo,
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
ins Spiel.
Wie dem auch sei, lassen wir @Bodennebel erstmal wieder antworten.
BFF
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.
BFF
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.
Die Fehlermeldung 1 wird seit Urzeiten meist von IOCTRL bzw jetzt DeviceIoControl erzeugt, insofern würde es passen.
Gruß
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.
Die Fehlermeldung 1 wird seit Urzeiten meist von IOCTRL bzw jetzt DeviceIoControl erzeugt, insofern würde es passen.
Gruß
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.
Gut, da hast Du natürlich recht, /COPY:DAT (Standardvorgabe) und /E (wegen /MIR) kann ich mir eigentlich schenken.
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.
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?
Das QNAP-NAS hat meines Wissens EXT4 als Filesystem und das Zielsystem WIN-FS ist NTFS formatiert.
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.
Schau mal in den Hilfen zu robocopy nach, was sich gegenseitig ersetzt/ergaenzt/ausschliesst. Macht am Ende halt die Zeile kuerzer.
Verdammt viele Optionen die Du Deinem robocopy reinwuergst.
Schau mal in den Hilfen zu robocopy nach, was sich gegenseitig ersetzt/ergaenzt/ausschliesst. Macht am Ende halt die Zeile kuerzer.
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?
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
Zitat von @BassFishFox:
Hallo,
In Ergaenzung was schon geschrieben wurde.
Heisst Dein Papierkorb wirklich so? Oder ist es eher so?
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.
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
Hallo hugonatter,
auch Dir vielen Dank für die Hilfe bei der Fehlersuche.
/XJ hatte ich mal im Rahmen einer Kopieraktion eines Windows-Systemlaufwerks entdeckt. Ist da sehr praktisch
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.
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.
/XJ hatte ich mal im Rahmen einer Kopieraktion eines Windows-Systemlaufwerks entdeckt. Ist da sehr praktisch
Die Fehlermeldung 1 wird seit Urzeiten meist von IOCTRL bzw jetzt DeviceIoControl erzeugt, insofern würde es passen.
Gruß
Gruß
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.
Hallo,
Wenn der Papierkorb so heisst, kann er auch so ausgeschlossen werden.
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.
Was sagt eigentlich das eventlog des Servers zu den "widerspenstigen Dateien"?
BFF
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.
robocopy "\\QNAP-NAS\Folder_001" "\\WIN-FS\Folder_001"
Oder habe ich Dich hier missverstanden?
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
Hallo BFF,
ich habe testweise das Ziel-Share \\WIN-FS\Folder_001 durch den Laufwerkspfad D:\Folder_001 ersetzt. Brachte aber keine Besserung
In der Ereignisanzeige konnte ich nichts finden. Ich will aber nicht ausschließen, dass ich an den falschen Stellen gesucht habe.
Gruß
Bodennebel
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.
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
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
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
Hast Du mal versucht, per Dateiexplorer auf dem Server, die betreffenden Dateien/Ordner zu kopieren?
Irgendwas muss an den Quelldaten schief gewickelt sein.
BFF
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
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
Hallo,
Das waere meine naechste Frage gewesen. Irgendwelche " ' ` ~ im Dateinamen?
BFF
Ich glaube, er hatte sich an den doppelten Anführungszeichen im Dateinamen gestört
Das waere meine naechste Frage gewesen. Irgendwelche " ' ` ~ im Dateinamen?
BFF