Robocopy und NTFS-Rechte

[zahni 554]

Hi,

 

ich versuche gerade einen für uns optimalen Migrationsweg unserer Filer von Windows 2008R2 auf eine Netapp mit cDot 8.3.2P6 herauszufinden.

Die Netapp ist per Kerberos zur Domain "gejoined"

Bei einem Versuch mit Robocopy unter (und aus) Windows 2012R2 bin ich auf  ein Problem gestoßen:

 

Wir haben aus irgendwelchen Gründen einige wenige Berechtigungen für Domain Local Groups vergeben.

Bei der Kopieroption /COPYALL ist es  nun so, dass aus mit unbekannten Gründen diese Rechte  hinterher fehlen. Globale Gruppen und einzelne User klappen.

Ich  kann sie zwar manuell neu anlegen, doch das ist nichts das Ziel.

 

Hat da jemand eine Idee?

 

PS: Ich sehe gerade: Wenn ich mit unserer Backup-Software auf die Netapp als CIFS-Share zurücksichere, klappt es. Wahrscheinlich kann mich Robocopy dann mal... ;)

 

-Zahni

 

[NilsK 2.958]

Moin,

 

das wundert mich. Robocopy ist es eigentlich völlig egal, um was für einen Gruppentyp es sich handelt, es überträgt halt die ACL-Einträge. Ob die aufgeglöst werden können und "funktionieren", ist dabei egal. Ich würde also eher auf einen anderen Fehler tippen.

 

Da wir in einem anderen Thread auch gerade über Gruppentypen diskutiert haben: Im Allgemeinen spricht nichts gegen Domänenlokale Gruppen, im Gegenteil, es spricht sogar einiges für deren Einsatz. Sie sind genau wie Globale oder Universale Gruppen im AD gespeichert. Durch die Eigenschaften, wer Mitglied werden kann und wo die Gruppe sichtbar ist (nur in der eigenen Domäne), kann man damit sinnvolle Rollenkonzepte bauen.

 

Gruß, Nils

[zahni 554]

Hi,

 

ok  - ich glaube, ich habe hier noch ein anderes Problem. Beim genauen Hinsehen fehlen auch noch andere Rechte und teilweise ganze Ordner.

Muss ich mal genau untersuchen. Eventuell ist Robocopy irgendwie mit dem normalen Backup-Job auf dem Windows-Server ins Gehege gekommen. 

Habe leider kein Log erstellt und es lief 10 Stunden.

Nicht dass cDot wieder irgendeinen Bug hat. Ich muss morgen mal die Release Notes der nachfolgenden Patch-Versionen lesen...

[magheinz 110]

Ich würde nach mal genau über die Rechte nachdenken.

Normalerweise baut man auf der Netapp ja eine neue Struktur auf. Sortiert die Daten je nach dedup, backup etc in volumes und qtrees. Ob das übernehmen der ACLs da sinnvoll ist muss man prüfen. Unter Umständen ist das mit der Vererbung dann nicht mehr so ganz passend.

 

Ich migriere auch gerade auf eine cdot-maschine. Die Rechte werden dann einmal komplett neu gesetzt.

Die Daten sind auf zwei SVMs verteilt (vorher eine 7mode Netapp, keine vfiler) und dann per widelinks und junktions wieder zu einem Dateibaum zusammengefügt.

[zahni 554]

Das mit dem Rechte  klappt schon so und kopieren ein paar Pfade an neue Orte.

 

Ich denke mal, ich spiele sicherheitshalber mal Patch 9 ein (Ontap 9.1 machen wir später).

Gründe sind u.a. CVE-2016-4341 (SMB Share Information Disclosure Vulnerability in Clustered Data ONTAP)

und "Poor performance due to SMB directory enumeration"

[magheinz 110]

Hast du die Daten in verschiedene volumes verteilt oder alles in einem?

[zahni 554]

So, ich habe jetzt noch ein wenig probiert und konnte den Effekt reproduzieren, ganz ohne Netapp. 

Lösung scheint der Schalte "/B" in Robocopy zu sein, warum auch immer. Es hat aber den Anschein, dass damit auch die Multithread-Funktionen abschaltet werden, jedenfalls wird nur noch ein einen Ordner gleichzeitig geschrieben.

 

Noch  eine weitere Anomalie: Ich habe zuerst versucht über das Root-Volume zu kopieren (C$-Share). Dort sind die Volumes als "Junction Point" eingehängt.

Kopiere ich auf so  einen Junction Point loggt Robocopy komische Fehler:

 

2017/01/26 11:40:33 ERROR 2 (0x00000002) Creating Destination Directory y:\junction point\mydir\

The system cannot find the file specified.

 

Angelegt werden die Ordner später aber trotzdem, wenn die  Dateien kopiert werden.

 

Erzeuge ich auf "junction point" ein Share und benutze es, verschwindet der Fehler.

[NilsK 2.958]

Moin,

 

mit /B forderst du das Backup-Recht an. Das ist irreführend bezeichnet - im Kern geht es darum, dass in diesem Modus robocopy auch Daten kopiert, auf die der User eigentlich keine Zugriffsrechte hat, sofern er über das Privileg "Backup files and folders" (oder so ähnlich) verfügt. Das ist bei Administratoren der Fall, man kann es aber auch einzeln erteilen oder über die Gruppe "Backup Operators" steuern.

 

Wenn es mit dem Schalter geht, ohne aber nicht, dann lagen die bisherigen Fehler einfach an fehlenden Zugriffsrechten. Für Backup- und Migrationsaufgaben sollte man den Schalter /B immer verwenden.

 

Gruß, Nils

[zahni 554]

Ich Domain-Admin, habe alle Rechte ;) 

Egal, dann halt so. Später probiere ich es noch mit einem Restore vom Band. Mal sehen, was schneller geht.

[NilsK 2.958]

Moin,

 

Ich Domain-Admin, habe alle Rechte ;)

 

nein. Du kannst dir alle Rechte verschaffen, aber du hast nicht alle Rechte. Das ist ein Unterschied. Und genau für diesen Unterschied brauchst du den Schalter /B. Immerhin ist robocopy eine der wenigen Applikationen, die das überhaupt können.

 

Gruß, Nils

PS. Domänen-Admin zum Datei-Kopieren? Tststs ... ;)

[djmaker 95]

Mit Ontap 9 wurde u.a. die Performance signifikant gesteigert. Die Version 9.1 ist jetzt GA. Ansonsten tut es auch 9.0P1. Das Upgrade sollte dank NDU kein Problem sein (außer Du hast sensible Apps per CiFS angebunden ). Ich sehe an der Stelle kaum Gründe für Ontap 8. Aber das nur nebenbei.

[magheinz 110]

ich würde ja noch mit ontap9 warten.

und das root-volume würde ich auch nicht als share-root nutzen sondern ein kleines extra volume.(20-50MB)

[zahni 554]

Die Netapp ist produktiv (mit FCP-Volumes). Ontap-Migration ist beim DL angefragt. Das lasse ich mal lieber den kaputt machen (einer muss ja "Schuld" haben ;) )

Gleichzeitig sollen noch die FC-Switche eine aktuelle Firmware bekommen. Der kann mir dann gleich  noch die wichtigsten Neuerungen zeigen.