ISCSI-Target "umswitchen", Zugriffsrechte
Mahlzeit Digitalfreunde,
es geht um eine Verständnisfrage zu iSCSI.
Die Idee ist, ein iSCSI-Target z.B. auf einem SYNOLOGY mal dem einen Windows-Host, mal einem anderen Windows-Host „anzuschliessen“. Das „anschliessen“ und „trennen“ kann man ja mit PowerShell Scripten per Hand erst einmal machen. Das Target darf eben nicht doppelt „angeschlossen“ / verbunden sein.
Innerhalb des Target soll NTFS Format vorliegen.
Aber: Gibt es dann Probleme mit der NTFS-Rechtestruktur innerhalb des Volumens im Target? Oder ist das Wurscht wenn man egal von welchem Windows-Host aus mit den identischen Usernamen & Passwort die Daten im Volume des Target bearbeiten möchte?
Es existiert kein Active Directory!
Hat da jemand eine „Ahnung“?
Danke
Kreuzberger
es geht um eine Verständnisfrage zu iSCSI.
Die Idee ist, ein iSCSI-Target z.B. auf einem SYNOLOGY mal dem einen Windows-Host, mal einem anderen Windows-Host „anzuschliessen“. Das „anschliessen“ und „trennen“ kann man ja mit PowerShell Scripten per Hand erst einmal machen. Das Target darf eben nicht doppelt „angeschlossen“ / verbunden sein.
Innerhalb des Target soll NTFS Format vorliegen.
Aber: Gibt es dann Probleme mit der NTFS-Rechtestruktur innerhalb des Volumens im Target? Oder ist das Wurscht wenn man egal von welchem Windows-Host aus mit den identischen Usernamen & Passwort die Daten im Volume des Target bearbeiten möchte?
Es existiert kein Active Directory!
Hat da jemand eine „Ahnung“?
Danke
Kreuzberger
Kommentieren
Teilen
Auf Facebook teilen
Auf X (Twitter) teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 671575
Url: https://administrator.de/forum/iscsi-target-umswitchen-zugriffsrechte-671575.html
Ausgedruckt am: 29.05.2025 um 09:05 Uhr
8 Kommentare
Neuester Kommentar
Moin,
Nein, dann sind die SIDs auf den unterschiedlichen Hosts nicht gleich, Benutzernamen sind Schall und Rauch bei NTFS.
Was spricht gegen eine Bereitstellung per Netzwerkfreigabe?
Gruß,
Avoton
Oder ist das Wurscht wenn man egal von welchem Windows-Host aus mit den identischen Usernamen & Passwort die Daten im Volume des Target bearbeiten möchte?
Es existiert kein Active Directory!
Es existiert kein Active Directory!
Nein, dann sind die SIDs auf den unterschiedlichen Hosts nicht gleich, Benutzernamen sind Schall und Rauch bei NTFS.
Was spricht gegen eine Bereitstellung per Netzwerkfreigabe?
Gruß,
Avoton
Moin,
habe das noch nicht getestet, aber an sich kann das nicht funktionieren. Denn ohne AD sind die User ja eben nicht identisch. Sie sehen nur gleich aus, haben aber intern eine unterschiedliche SID und sehen daher für das Dateisystem unterschiedlich aus.
Was theoretisch gehen könnte: die Berechtigungen einmal von dem einen, einmal von dem anderen System aus setzen. Wenn dann der User "Test" von System 1 berechtigt wird, das Target aber an System 2 hängt, müsste dort ein nicht aufzulösender User in den Berechtigungen stehen. Sollte dann egal sein, wenn der gleichnamige User "Test" von System 2 ebenfalls berechtigt wurde.
In diesem Sinne, einfach mal in einer Testwiese ausprobieren.
Gruß
DivideByZero
habe das noch nicht getestet, aber an sich kann das nicht funktionieren. Denn ohne AD sind die User ja eben nicht identisch. Sie sehen nur gleich aus, haben aber intern eine unterschiedliche SID und sehen daher für das Dateisystem unterschiedlich aus.
Was theoretisch gehen könnte: die Berechtigungen einmal von dem einen, einmal von dem anderen System aus setzen. Wenn dann der User "Test" von System 1 berechtigt wird, das Target aber an System 2 hängt, müsste dort ein nicht aufzulösender User in den Berechtigungen stehen. Sollte dann egal sein, wenn der gleichnamige User "Test" von System 2 ebenfalls berechtigt wurde.
In diesem Sinne, einfach mal in einer Testwiese ausprobieren.
Gruß
DivideByZero
. . . und wenn man einfach alle Rechte frei gib? Also JEDER darf alles!?!?!?
Wäre in dem Fall kein Drama.
Kreuzberger
Wäre in dem Fall kein Drama.
Kreuzberger
Dann könnte das so funktionieren.
Achte aber wirklich darauf, dass das Target niemals gleichzeitig gemountet wird, das mag NTFS gar nicht.
Gruß,
Avoton
Achte aber wirklich darauf, dass das Target niemals gleichzeitig gemountet wird, das mag NTFS gar nicht.
Gruß,
Avoton
@Avoton
Danke.
Gäbe es denn eine Möglichkeit, das per PowerShell abzufragen, ob ein iSCSI Target „in use“ ist?
Kreuzberger
Danke.
Gäbe es denn eine Möglichkeit, das per PowerShell abzufragen, ob ein iSCSI Target „in use“ ist?
Kreuzberger
Moin,
aus Sicht des NAS ist das kein Problem ein Shared Volume bereitzustellen. Dem Volume und Dateisystem (in dem Fall NTFS) macht das auch nichts aus.
Bei mehr als einem Host spricht man aber normalerweise von einem Cluster, mit entsprechenden Funktionen, dass nicht gleichzeitig an den gleichen Daten rumgefummelt wird.
Das manuell regeln zu wollen hört sich "komisch" an...
Möchtest du mal darstellen was der Hintergrund davon ist?
Direkt SMB auf dem NAS nutzen oder DFS davor schalten kommt nicht in Frage?
Gruß
aus Sicht des NAS ist das kein Problem ein Shared Volume bereitzustellen. Dem Volume und Dateisystem (in dem Fall NTFS) macht das auch nichts aus.
Bei mehr als einem Host spricht man aber normalerweise von einem Cluster, mit entsprechenden Funktionen, dass nicht gleichzeitig an den gleichen Daten rumgefummelt wird.
Das manuell regeln zu wollen hört sich "komisch" an...
Möchtest du mal darstellen was der Hintergrund davon ist?
Direkt SMB auf dem NAS nutzen oder DFS davor schalten kommt nicht in Frage?
Gruß
Moin,
sobald du das ISCSI LUN einmal "unsauber" trennst ist das Dateisytem oft schrott und ntfs ist da sehr sensibel.
Ob ein Taget verbunden ist sieht man in Windows im iscsi Client (ps: Get-IscsiTarget) und bei Synolgy im Sanmanager.
Gruß
Egal wie du es machst, iscsi hat immer nur EINEN CHEF, bei vmware hv sieht das oft anders aus als es tatsächlich ist.
sobald du das ISCSI LUN einmal "unsauber" trennst ist das Dateisytem oft schrott und ntfs ist da sehr sensibel.
Ob ein Taget verbunden ist sieht man in Windows im iscsi Client (ps: Get-IscsiTarget) und bei Synolgy im Sanmanager.
Gruß
Egal wie du es machst, iscsi hat immer nur EINEN CHEF, bei vmware hv sieht das oft anders aus als es tatsächlich ist.
@ElmerAcmeee
Danke
Es ist ein kleines Netz, nur wenige Computer sind da dabei, und es sind auch immer wieder mal Freelancer-PCs dabei, die kurzweilig da im Netz sind.
Es geht da nun im Disziplinierung und Organisation der Projektarbeit. Es darf aus Lizenz-Gründen und aus technischen Gründen nie mehr als eine Person auf jeweils die Projektdaten zugreifen.
Das mit Wechselplatten zu machen ginge zwar, aber hat einige substantielle Nachteile: Steckverbindung instabil, Steckverbindung inkompatibel (Thunderbolt, USB, etc.), die Wechselplatte ist verschwunden, kein erzwingbares Backup.
Zudem müssen zwingend die Laufwerksbuchstaben wegen Verknüpfungen zu Bestandsdaten immer identisch sein.
Es ist noch in der Denkphase, aber ich will das Wechselplatten-Chaos beenden.
Vor allem aber dann auch ein erzwungenes Backup erreichen.
Idee: User soll heute Projekt „4“ bearbeiten. Schaltet die Workstation ein, startet das PowerShell Script Projekt-4 und hat Exclusivzugang zu den Daten auf Laufwerk „i:“. Niemand anderes kann derweil an diese Daten, auch nicht nur mal neugierig gucken und dann doch mal klicken.
iSCSI bietet mir eben die Möglichkeit, alles als weiteres, internes Laufwerk zu betrachten, was dann Vorteile hat. Die Projekte werden aber nicht durchgehend von den selben Leuten an den selben Workstations bearbeitet, jedoch aber immer im selben, lokalen Netz.
Ist das Projekt fertig werden alle Daten aus dem iSCSI Volume archiviert wie sie sind, dort gelöscht, Platz für Neues.
Kreuzberger
Danke
Es ist ein kleines Netz, nur wenige Computer sind da dabei, und es sind auch immer wieder mal Freelancer-PCs dabei, die kurzweilig da im Netz sind.
Es geht da nun im Disziplinierung und Organisation der Projektarbeit. Es darf aus Lizenz-Gründen und aus technischen Gründen nie mehr als eine Person auf jeweils die Projektdaten zugreifen.
Das mit Wechselplatten zu machen ginge zwar, aber hat einige substantielle Nachteile: Steckverbindung instabil, Steckverbindung inkompatibel (Thunderbolt, USB, etc.), die Wechselplatte ist verschwunden, kein erzwingbares Backup.
Zudem müssen zwingend die Laufwerksbuchstaben wegen Verknüpfungen zu Bestandsdaten immer identisch sein.
Es ist noch in der Denkphase, aber ich will das Wechselplatten-Chaos beenden.
Vor allem aber dann auch ein erzwungenes Backup erreichen.
Idee: User soll heute Projekt „4“ bearbeiten. Schaltet die Workstation ein, startet das PowerShell Script Projekt-4 und hat Exclusivzugang zu den Daten auf Laufwerk „i:“. Niemand anderes kann derweil an diese Daten, auch nicht nur mal neugierig gucken und dann doch mal klicken.
iSCSI bietet mir eben die Möglichkeit, alles als weiteres, internes Laufwerk zu betrachten, was dann Vorteile hat. Die Projekte werden aber nicht durchgehend von den selben Leuten an den selben Workstations bearbeitet, jedoch aber immer im selben, lokalen Netz.
Ist das Projekt fertig werden alle Daten aus dem iSCSI Volume archiviert wie sie sind, dort gelöscht, Platz für Neues.
Kreuzberger
