Freigaben von Windows nach Netapp kopieren

[zahni 559]

Hi,

 

vielleicht hat jemand mal einen Tipp. Ich suche gerade  nach einer Lösung, wie ich Windows-Freigaben inkl. der ACL auf eine Netapp (cDot 8.3/9) übertragen kann.

Dabei geht es mit nicht um die NTFS-Rechte. Das macht Robocopy ganz gut. LANMANSERVER  auf  der Registry kann ich schlecht exportieren ;)

 

-Zahni

[NilsK 2.969]

Moin,

 

früher haben wir ein Kopierprogramm von ScriptLogic für sowas verwendet. Gehörte zu Quest, dann zu Dell. Weiß nicht, wo es jetzt gelandet ist.

 

Gruß, Nils

[zahni 559]

Hm, Du meinst wohl  https://shop.quest.com/682/purl-Secure-Copy . Die  verkaufen echt eine "30 Tage Lizenz" ;)

Ich habe mir noch die Powershell-Erweitung von Netapp heruntergeladen. Mal sehen, was damit geht.

[magheinz 110]

Sehe ich das richtig das du ACLs auf Shareebene mit übertragen willst?

Alle mir bekannten Netapp Bestpractises sagen hier: Share-ACL= rw everyone. Berechtigungen dann über NTFS-ACLs setzen.

Je nachdem was du da vorhast könnte man noch etwas über die export-policies reissen.

[zahni 559]

Nö, rw Everyone macht man auch unter Windows nicht. Besonders  nicht, wenn Du die Kontrolle über die NTFS-Rechte behalten willst.

Aber  wie gesagt, mit  dem Powershell-Teil kann man vermutlich was bauen. Schaue  ich mit demnächst an. Soweit  ich  das sehe, gibt es CMDLets zum Erstellen von Freigaben auf der Netapp...

[NilsK 2.969]

Moin,

 

Nö, rw Everyone macht man auch unter Windows nicht.

 

doch, genau das gilt als Best Practice, solange keine besonderen Anforderungen bestehen. Genauer sogar Everyone:Full Control, auch bekannt als Null-ACL.

 

[Datei- und Freigabeberechtigungen in Windows | faq-o-matic.net]
http://www.faq-o-matic.net/2015/12/28/datei-und-freigabeberechtigungen-in-windows/

 

Nur auf die Weise lässt sich vorhersagen und nachvollziehen, welche Berechtigungen gelten. Und nur auf die Weise sind serverübergreifende Migrationen handhabbar.

 

Gruß, Nils

bearbeitet 23. Januar 2017 von NilsK

[zahni 559]

Hm, auch darüber kann man trefflich diskutieren. Natürlich sind NTFS-Berechtigungen führend. Bei uns stellen die Freigabe-Berechtigungen nur sicher, dass sich ein User  nicht verirrt.

Vermutlich kann man das auch weglassen.  Auf jeden Fall ist die höchste Berechtigung "Ändern". Wir hatten in der Vergangenheit zu viele Probleme mit dem Besitz-Recht, bei dem der User dann doch wieder NTFS-Rechte verstellen darf.

[Dukel 457]

Gegen das verirren gibt es ABE.

 

Gegen das Besitz-Recht gibt es etwas im Link von Nils:

 

Die eine Ausnahme: Benutzer sollen keine Berechtigungen ändern

Oben haben wir empfohlen, dass die Freigabeberechtigungen immer auf “Jeder: Vollzugriff” stehen sollten. Dadurch ist gewährleistet, dass die NTFS-Berechtigungen für Ordner (und Dateien) immer “eins zu eins” gelten.

In manchen Fällen sollen Anwender allerdings selbst nicht in die Berechtigungen eingreifen dürfen. Das ist auf der Ebene der NTFS-Berechtigungen unter Umständen nur schwierig (oder auch gar nicht) zu erreichen. Sobald nämlich ein Benutzer eine neue Datei anlegt, ist er Besitzer dieser Datei. Und der Besitzer hat immer volle Verfügungsgewalt über die Datei, darf also auch deren Berechtigungen ändern. So kann er etwa die Administratoren vom Zugriff aussperren – das ist zwar nicht dauerhaft wirksam (denn die Administratoren kann man in Windows nicht effektiv am Zugriff hindern), aber es führt zu unerwünschten Problemen, etwa bei der Datensicherung.

Eine Variante der Empfehlung “Nur Vollzugriff auf Freigabeebene” lautet daher: Administratoren des Dateiservers erhalten auf der Freigabe Vollzugriff. Die Gruppe “Benutzer” (oder “Authentifizierte Benutzer”) erhält auf der Freigabe nur “Ändern”-Berechtigung. Dadurch können die Benutzer alles tun, was man “üblicherweise” mit Dateien macht: Lesen, Schreiben, Erzeugen, Löschen – vorausgesetzt, die NTFS-Berechtigungen lassen dies zu. Sie können aber auf keinen Fall Berechtigungen ändern, auch dann nicht, wenn sie Besitzer einer Datei sind. Dies ist nämlich mit dem “Ändern”-Recht einer Freigabe nicht erlaubt.

Vorsicht aber: Auch diese Ausnahme sollte man nur da einsetzen, wo wirklich Bedarf besteht. Jede Ausnahme erhöht die Komplexität und erschwert die Fehlersuche.