Berechtigungen sind der schwierigste Teil jeder Isilon-Migration. OneFS hat ein einheitliches ACL-Modell, das NFS- und SMB-Clients auf den gleichen Dateien koexistieren lässt — aber die meisten Zielplattformen funktionieren nicht so. Verschieb die Daten, ohne das Berechtigungsmodell zu verstehen, und du bekommst am Montag Tickets wegen gebrochenem Zugriff.
Dieser Guide behandelt, wie OneFS-Berechtigungen tatsächlich funktionieren, was bei der Migration kaputt geht und wie du den Zugriff auf dem Ziel erhältst.
Die meisten Dateisysteme speichern Berechtigungen in einem Format: POSIX-Mode-Bits (Unix) oder NTFS Security Descriptors (Windows). OneFS verbindet beide Welten mit einem flexiblen internen Modell: Dateien können sich im POSIX-Modus (nur Standard-Mode-Bits) oder im ACL-Modus (eine reichhaltigere, auf der Platte gespeicherte ACL, erstellt wenn Berechtigungen über SMB oder NFSv4-ACL-Operationen geändert werden) befinden.
Wenn ein NFS-Client ls -l ausführt, präsentiert OneFS POSIX-Mode-Bits — entweder direkt (POSIX-Modus-Dateien) oder aus der ACL synthetisiert. Wenn ein SMB-Client den Sicherheits-Tab im Windows Explorer öffnet, präsentiert OneFS einen Windows-Style Security Descriptor. Beide Ansichten stammen von den gleichen On-Disk-Berechtigungsdaten.
OneFS On-Disk ACL
┌─────────────────┐
│ ACE 1: ALLOW │
│ user:alice │
│ rwx │
│ │
│ ACE 2: ALLOW │
│ group:finance │
│ r-x │
│ │
│ ACE 3: ALLOW │
│ everyone │
│ r-- │
└────────┬────────┘
│
┌──────────────┼──────────────┐
▼ ▼
NFS-Client-Ansicht SMB-Client-Ansicht
┌──────────────────┐ ┌──────────────────────┐
│ -rwxr-xr-- alice │ │ alice: Full Control │
│ finance │ │ finance: Read & Exec │
│ │ │ Everyone: Read │
└──────────────────┘ └──────────────────────┘
OneFS unterstützt drei ACL-Richtlinien-Modi, die steuern, wie NFS- und SMB-Berechtigungsänderungen interagieren:
UNIX only
Windows only
Balanced (Multiprotokoll)
# ACL-Richtlinie deines Clusters prüfen
isi auth settings acls view
# Pro-Zone-Overrides
isi zone zones view <zone_name> --format=json | grep -i acl
Kenne deinen Modus vor der Migration
Der ACL-Richtlinien-Modus bestimmt, wie Berechtigungen aussehen, wenn du sie auf eine Nicht-Isilon-Plattform kopierst. Cluster im UNIX-only-Modus sind am einfachsten zu migrieren. Cluster im Balanced-Modus erfordern die sorgfältigste Planung. Prüfe den Modus für jede Access Zone — sie können sich unterscheiden.
Unix identifiziert Benutzer über UID/GID. Windows identifiziert Benutzer über SID. OneFS verbindet beides:
| Identitätsquelle | Format | Beispiel |
|---|---|---|
| Unix UID/GID | Numerisch | uid=1001, gid=500 |
| Windows SID | String | S-1-5-21-3623811015-...-1001 |
| Isilon intern | OneFS-Mapping | Verknüpft UID und SID für den gleichen Benutzer |
Wenn alice sich über NFS verbindet, löst OneFS ihre UID zu einer internen Identität auf. Wenn sie sich über SMB verbindet, löst OneFS ihre SID zur gleichen internen Identität auf. Die On-Disk-ACL referenziert die interne Identität, und OneFS übersetzt sie in das passende Format für jedes Protokoll.
OneFS löst Identitäten über mehrere Quellen auf, in Prioritätsreihenfolge:
uidNumber, gidNumber) verknüpft mit AD-Konten# AD-Konfiguration prüfen
isi auth ads list --format=table
# LDAP-Provider prüfen
isi auth ldap list --format=table
# Mapping eines bestimmten Benutzers auflösen
isi auth mapping token alice
isi auth mapping token --uid=1001
Auto-gemappte SIDs existieren auf dem Ziel nicht
Wenn dein Cluster Auto-Mapping nutzt (algorithmische UID-SID-Konvertierung), sind diese SIDs Isilon-spezifisch. Sie werden auf keiner anderen Plattform aufgelöst. Dateien im Besitz von auto-gemappten Identitäten werden auf einem Windows-Ziel als “unknown SID” angezeigt oder könnten auf einem Linux-Ziel stillschweigend der falschen UID zugeordnet werden.
Häufige Mapping-Probleme, die du vor der Migration identifizieren solltest:
# Dateien mit nicht gemappten SIDs finden (verwaiste Windows-Besitzer)
isi_for_array -s 'find /ifs/data -maxdepth 3 -exec stat -f "%u %g %N" {} \;' \
2>/dev/null | grep -E "^(4294967294|65534)" | head -20
# Dateien im Besitz von nobody/nogroup finden (Mapping-Fehler)
find /ifs/data -user nobody -o -group nogroup 2>/dev/null | head -20
Was passiert: Du kopierst Dateien von einem Isilon mit einem POSIX-only-Tool (rsync ohne -A), und Windows-ACLs werden stillschweigend auf einfache POSIX-Mode-Bits reduziert.
Vorher (Isilon):
alice: Read, Write, Execute, Delete, Change Permissions
finance-managers: Read, Write, Execute
finance-readonly: Read, Execute
Domain Users: Read
Nachher (Ziel, nur POSIX):
-rwxrwx--- alice finance
Die granularen Windows-ACLs — separate Delete-Berechtigung, Change-Permissions-Recht, die Read-only-Gruppe — sind alle weg. finance-managers und finance-readonly werden in den einzelnen Gruppenbesitzer zusammengelegt.
Auswirkung: Benutzer, die spezifische Windows-Berechtigungen hatten, verlieren oder erhalten Zugriff, den sie nicht haben sollten.
Was passiert: Dateien, die über SMB migriert werden (Robocopy mit /COPYALL), behalten Windows-SIDs bei, aber das Ziel kann sie nicht auflösen, weil es einer anderen AD-Domäne beigetreten ist oder eine andere Vertrauensbeziehung nutzt.
Symptome:
S-1-5-21-3623811015-...)icacls zeigt nicht aufgelöste SIDsLösung: ACLs auf dem Ziel neu setzen. Erst ACLs speichern, dann mit SID-Substitution wiederherstellen:
# Schritt 1: Aktuelle ACLs speichern
icacls "D:\data" /save acl_backup.txt /T /C
# Schritt 2: Mit SID-Substitution wiederherstellen
icacls "D:\data" /restore acl_backup.txt /substitute "S-1-5-21-OLD-DOMAIN" "S-1-5-21-NEW-DOMAIN" /C
Was passiert: Der Quell-Isilon löst alice über LDAP zu UID 1001 auf. Der Ziel-Linux-Server löst alice zu UID 5001 auf, weil er eine andere LDAP-Basis oder ein lokales /etc/passwd nutzt.
Symptome:
ls -l zeigt numerische UIDs statt BenutzernamenLösung: Stelle sicher, dass das Ziel die gleiche Identitätsauflösung nutzt (gleiches LDAP, gleiches AD mit RFC2307) oder mappe UIDs während der Migration um.
Was passiert: Du erhältst NFSv4-ACLs während der Migration (rsync -A), aber der Ziel-NFS-Server oder das Dateisystem unterstützt keine NFSv4-ACLs.
| Ziel | NFSv4-ACL-Support |
|---|---|
| Linux + ext4 | Nur POSIX-ACLs; kein nativer NFSv4-ACL-Support |
| Linux + XFS | Nur POSIX-ACLs; kein nativer NFSv4-ACL-Support |
| Linux + ZFS (OpenZFS) | Eingeschränkt; acltype=nfsv4 noch nicht upstream gemergt |
| TrueNAS (ZFS) | Voller NFSv4-ACL-Support |
| NetApp ONTAP | Voller NFSv4-ACL-Support |
| Qumulo | Voller NFSv4-ACL-Support |
# Globale ACL-Richtlinie prüfen
isi auth settings acls view
# Beispiel-Datei-ACLs aus Schlüsselverzeichnissen
ls -le /ifs/data/finance/ | head -20
ls -le /ifs/data/hr/ | head -20
Das -e-Flag zeigt auf dem Isilon die erweiterte ACL. Wenn du einfache POSIX-Einträge siehst (user::rwx, group::r-x, other::r--), sind die Berechtigungen POSIX-kompatibel und leicht zu migrieren. Wenn du Windows-Style ACEs mit spezifischen Rechten siehst (allow user alice read,write,execute,delete), brauchst du einen Plan dafür.
Prüfe, wie viele Dateien komplexe ACLs haben, die über einfache POSIX-Mode-Bits hinausgehen:
# Prüfen, wie viele Dateien Windows-Style ACLs haben
find /ifs/data -type f -exec ls -le {} \; 2>/dev/null | \
grep -c "ALLOW\|DENY" | head -1
# PermissionRepair-Job zur Vorschau der Konvertierung nutzen (Dry Run)
isi job start permissionrepair --mode=convert --mapping-type=global \
--template=posix --dry-run --paths=/ifs/data/finance
Von einer Windows-Maschine, die der gleichen Domäne beigetreten ist:
# Share-Level- und File-Level-ACLs auditieren
icacls "\\isilon\finance" /T /C /Q > acl_audit.txt
# Oder smbcacls von Linux aus nutzen
smbcacls //isilon/finance / -U admin
smbcacls //isilon/finance /restricted -U admin
Bevor du Produktionsdaten migrierst, teste mit einem repräsentativen Beispiel:
| Testfall | Quelle (Isilon) | Erwartet auf Ziel | Bestanden? |
|---|---|---|---|
| alice liest finance/ über NFS | OK | OK | |
| alice schreibt finance/ über SMB | OK | OK | |
| bob liest finance/ über NFS | Verweigert | Verweigert | |
| finance-readonly liest über SMB | Nur Lesen | Nur Lesen | |
| Domain Users listet Verzeichnis über SMB | OK | OK |
# POSIX-ACLs und Extended Attributes erhalten
rsync -avHAX --progress \
/mnt/isilon/ /mnt/dest/
# Flag-Erklärung:
# -a Archive-Modus (Berechtigungen, Besitz, Zeitstempel)
# -H Hardlinks erhalten
# -A POSIX-ACLs erhalten (getfacl/setfacl)
# -X Extended Attributes erhalten (xattr)
rsync -A erhält nur POSIX-ACLs
Das -A-Flag erhält POSIX-ACLs (getfacl/setfacl-Format), nicht NFSv4-ACLs oder Windows-NTFS-ACLs. Wenn dein Isilon den Windows-Modus oder Balanced-Modus nutzt, erfasst rsync nur die synthetisierte POSIX-Darstellung — du verlierst granulare Windows-Berechtigungen.
# Alle Dateiinformationen inklusive Sicherheit kopieren
robocopy \\isilon\share \\destination\share /MIR /COPYALL /MT:16 /R:3 /W:5
# /COPYALL = /COPY:DATSOU
# D = Data
# A = Attributes
# T = Timestamps
# S = Security (NTFS ACLs)
# O = Owner info
# U = Auditing info (SACL)
Voraussetzungen:
Für Ziele, die NFSv4-ACLs unterstützen (ZFS, NetApp, Qumulo):
# Auf der Quelle: NFSv4-ACLs exportieren
find /mnt/isilon -type f -exec sh -c '
echo "FILE: $1"
nfs4_getfacl "$1"
echo "---"
' _ {} \; > nfsv4_acls.txt
# Auf dem Ziel: NFSv4-ACLs anwenden
# (nfsv4_acls.txt parsen und mit nfs4_setfacl anwenden)
syncopio erhält POSIX-Berechtigungen, Besitzrechte und Zeitstempel während des Transfers. Die Berechtigungen jeder Datei werden auf dem Ziel als Teil der Migration verifiziert — kein separater Audit-Durchlauf nötig. Für Multiprotokoll-Umgebungen, in denen POSIX-Berechtigungen auf dem Ziel ausreichen, handhabt syncopio Datenverschiebung und Verifizierung in einem einzigen Workflow.
Nach der Migration systematische Berechtigungsprüfungen durchführen:
#!/bin/bash
# compare-permissions.sh — Berechtigungen zwischen Quelle und Ziel vergleichen
SOURCE="/mnt/isilon"
DEST="/mnt/dest"
DIRS="finance hr legal shared"
for dir in $DIRS; do
echo "=== Prüfe $dir ==="
# Besitz vergleichen
diff <(stat -c "%U:%G %a %n" "$SOURCE/$dir"/* 2>/dev/null | sort) \
<(stat -c "%U:%G %a %n" "$DEST/$dir"/* 2>/dev/null | sort)
# POSIX-ACLs vergleichen
diff <(cd "$SOURCE" && getfacl -R "$dir" 2>/dev/null) \
<(cd "$DEST" && getfacl -R "$dir" 2>/dev/null)
echo ""
done
Teste den tatsächlichen Zugriff, nicht nur die Berechtigungen. Für jedes kritische Verzeichnis:
# NFS-Zugriff als verschiedene Benutzer testen
su - alice -c "ls /mnt/dest/finance/" # Soll: Erfolg
su - alice -c "touch /mnt/dest/finance/test" # Soll: Erfolg
su - bob -c "ls /mnt/dest/finance/" # Soll: Fehlschlag
su - charlie -c "cat /mnt/dest/finance/report.xlsx" # Soll: Erfolg (nur Lesen)
Für SMB von Windows-Clients testen:
# SMB-Zugriff testen
dir \\destination\finance # Soll: Erfolg
echo test > \\destination\finance\test.txt # Soll: Erfolg für Schreiber
del \\destination\finance\test.txt # Soll: Fehlschlag für Nur-Lesen-Benutzer
Vor dem Cutover testen, nicht danach
Führe deine Zugriffstestmatrix während des Migrationsfensters durch — nicht nach dem Cutover. Wenn Berechtigungen kaputt sind, willst du das wissen, während die Benutzer noch auf dem Isilon sind, nicht wenn sie Tickets schreiben. Mounte das Ziel neben der Quelle und teste beides.
Ist dein Isilon im UNIX-only-ACL-Modus?
-A-Flag erhält alles. Du bist gut aufgestellt.Unterstützt dein Ziel NTFS-ACLs? (NetApp ONTAP, Windows Server, Samba 4)
/COPYALL über SMB erhält die vollen Windows-ACLs.Unterstützt dein Ziel NFSv4-ACLs? (ZFS, Qumulo, NetApp)
nfs4_getfacl/nfs4_setfacl oder Hersteller-Migrationstools.POSIX-only-Ziel (ext4, XFS ohne ACL-Tools)