Jump to content

Robocopy und NTFS-Rechte


Der letzte Beitrag zu diesem Thema ist mehr als 180 Tage alt. Bitte erstelle einen neuen Beitrag zu Deiner Anfrage!

Recommended Posts

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

 

Link to comment

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

Link to comment

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...

Link to comment

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.

Link to comment

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"

Link to comment

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.
Link to comment

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

Link to comment

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 ... ;)

Link to comment
Der letzte Beitrag zu diesem Thema ist mehr als 180 Tage alt. Bitte erstelle einen neuen Beitrag zu Deiner Anfrage!

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...