Netapp-CIFS-NFS-Verwirrung

Benutzer für CIFS und NFS

Auf dem Netapp-Filer im Netzlabor ist ein Volume mit Unix-Security-Style für die Nutzung als NFS-Export und CIFS-Share angelegt.

Ich hatte vor einiger Zeit im Netapp System Manager einen Benutzer angelegt und ihn den Gruppen Administratoren und User zugeordnet.

Ein NFS-Export ist mit den notwendigen Zugriffrechten für Hosts (in dem Fall MacOS-Rechner) angelegt. Ebenso ist ein CIFS-Homeverzeichnispfad in das Volume wie auch ein Share über das gesamte Volume mit entsprechenden Zugriffsrechten für den Benutzer konfiguriert (eins von beide hätte gereicht).

Damit konnte ich wie erwartet mit CIFS z. B. von MacOS aus (Pfad smb://…) auf das Share und direkt auf das Homeverzeichnis zugreifen. Unter NFS war das Mounten und ein Zugriff ebenso möglich. Beide Mount waren gleichzeitig im MacOS Finder zu sehen und verwendbar.

Nun zeigte sich aber ein unerwarteter Effekt: Im Homeverzeichnis des Benutzers habe ich vermutlich über den CIFS-Mount Ordner angelegt. Die waren auch unter CIFS normal schreib- und lesbar. Wenn ich aber über NFS auf das Verzeichnis geschaut habe, waren die Ordner geschützt – also nicht zu öffnen. Ich hatte keine Zugriffsrechte darauf. Als Eigentümer der Ordner war über den NFS-Mount root angetragen. Über den CIFS-Mount aber der Benutzer, der den Ordner angelegt hat. Also auf zwei verschiedenen Wegen den gleicher Ordner angeschaut, hatte er verschiedene Eigentümer und Zugriffsrechte.

Langes Suchen förderte zwei Erkenntnisse über die Funktionsweise der Netapp zu Tage:

– Es findet ein Mapping von CIFS auf Unix-Benutzer statt. Mit „options.wafl.nt_admin_priv_map_to_root on“ war eingestellt, dass Zugriffsrechte der Gruppe der NT-Administratoren auf Unix-root abgebildet werden. Mein angelegter Benutzer war der Gruppe der Administratoren zugeordnet. Somit wird mein (NT-)Benutzer auf Unix-root abgebildet. Dies zeigte auch der Befehl „wcc -s <Benutzer>“ an der Ontap-Shell, der das mapping von NT-Benutzern nach Unix-Nutzern anzeigt.

– Ein Ordner, den ein NT-Benutzer aus der Gruppe der Administratoren über CIFS anlegt, bekommt aus UNIX-Sicht und damit in NFS den Eigentümer root. Die Wirkung war also, dass der Ordner aus CIFS-Sicht dem angemeldeten Benutzer gehören, aus Unix- (und damit wohl auch NFS-) Sicht aber root. Also gleicher Ordner, aber je nach Zugang unterschiedliche Eigentümer.

Um die Besitzverhältnisse der Ordner unter CIFS und NFS konkruent zu bekommen, habe ich zunächst meine Benutzer auch in der /etc/passwd im Netapp-Filer angelegt (mit wrfile -a eine Zeile mit dem Benutzernamen angelegt, dass Passwort unter einem Linux mit htpasswd -nd erzeugt). Damit ist dann ein automatisches Mapping des NT-Benutzers auf den gleichlautenden Unix-Nutzer ermöglicht. Trotzdem wurde das Mapping noch nicht automatisch geändert wegen der options…. wie oben beschrieben.

Also weiter: Zwei mögliche Fortsetzungen
a) Die Option zum Mapping administrativer NT-Benutzer auf root abschalten oder
b) Den Benutzer aus der Gruppe der Administratoren nehmen.
Fall a) hat Folgen, die an anderer Stelle unangenehm sein könnten.
Fall b) ist der angemessenere Weg, da er den NT-Benutzer zu dem macht, was er auch sein sollte – ein „normaler“ Benutzeraccount.

Damit (Fall b) funktioniert nun das Mapping in der Netapp wie es soll und der Ordner hat aus beiden Sichten den gleichen Eigentümer.

Triple Boot auf MacMini – Installation von Grund auf

Im Netzwerklabor laufen 14 Mac Minis mit drei Betriebssystemen:

  • Mac OS Lion (10.7.4)
  • Windows 7
  • Ubuntu 12.04

Hier wird beschrieben, wie die Triple Boot-Möglichkeit von Grund auf installiert ist. Insgesamt ist gegenüber früheren Triple-Boot-Versionen mehr Handarbeit notwendig. Jedenfalls entstehen Bootprbleme aus gleich mehreren Gründen:

1. Mac OS 10.7  legt eine Recovery-Partition anlegt, die einen Platz in der automatisch erzeugten MBR-Partitionsliste belegt und damit entweder Windows oder Ubuntu außen vor wären (siehe weiter unten).

2. gparted von Ubuntu 11.10 hat ein Problem, das ebenfalls zu einer unbrauchbaren Installation führen kann (z. B. Verkleinerung von NTFS endet mit Fehler und unbrauchbarer Windows-Partition)

3. Grub will nicht in eine Partition, sondern in den MBR installiert werden, sonst kommt eine Fehlermeldung während der Installation.

Letzten Endes bin ich zum Ziel gekommen, indem ich

– die Partitionen in zwei Schritten (einer in Mac OS, einer in gparted-live) angelegt habe und

– manuell aus Ubuntu heraus einen neuen Hybrid-MBR erzeugt habe und

– die Bootkonfigurationen von Windows und Ubuntu korrigiert habe.

Ablauf:

  • Partitionierung und Mac OS:
    • Mac OS X-Installation von CD (!) starten
    • Festplattendienstprogramm aufrufen und Festplatte komplett löschen
    • im Festplattendienstprogramm drei Partitionen anlegen: erste („Mac HD“) für Mac OS, zweite („BOOTCAMP“) für Windows (FAT), dritte frei lassen.
    • jetzt Mac OS normal installieren
    • in Mac OS refit installieren
    • Bootcamp-Assistent laufen lassen, um Treiber zu laden und auf CD brennen oder auf USB-Stick. Keine Windows 7-Installation starten.
    • Neustart
  • Windows 7 installieren
    • Windows 7-CD booten, BOOTCAMP-Partition formatieren lassen,  wird dabei mit NTFS angelegt
    • Installation normal durchlaufen lassen
    • von Mac OS X-DVD Windows-Treiber installieren
    • Neustart
  • Gparted-Live-CD booten
    • Root-Partition für Ubuntu anlegen, bei mir ext4-Format
    • Swap-Partition anlegen 1-2fache Größe des RAM
    • Ich habe keine Boot-Partition angelegt, könnte man aber tun. Dann aber aufpassen bei MBR-Erzeugung.
    • Ich habe nicht mehr probiert, das aus dem Gparted des Ubuntu-Installers zu machen, könnte aber auch funktionieren, wenn man NTFS unangetastet lässt und Grub in den MBR schreiben lässt (default bei der Installation)
    • Neustart
  • Ubuntu  11.10 installieren.
    • Von Ubuntu-CD booten.
    • Manuelle Partitionierung: Root-Partition an / zuweisen, Swap-Partition wird automatisch hinzugenommen
    • Ich habe Grub in den MBR installieren lassen (wird später korrigiert)
    • Installation normal durchlaufen lassen
    • Neustart
  • Nach Linux booten und
    • grub-setup -f /dev/sda5, um Grub in die Partition zu installieren. Grub meckert viel, geht aber. Dann update-grub.
    • Programm gdisk installieren und aufrufen
      • mit p EFI-Partitionen ansehen
      • mit r und o aktuelle MBR-Partitonstabelle ansehen (nur aus Spaß), dann h, um neuen Hybrid-MBR zu erzeugen
        • drei Partitionen für MBR angeben: Nr. 1 (EFI-Partition), Nr. der Windows-Partition und Nummer der Linux-Root-Partition
        • erste Frage mit ja beantworten (EFI-Start in ersten Eintrag)
        • bei folgenden Fragen für erste beiden Partitionen Typ bestätigen und Boot-Flag mit Nein beantworten. Für Linux-Partition habe ich Typ auf 83 geändert und Boot-Flag gesetzt (war später aber wieder weg).
      • mit w auf Platte schreiben und mit q raus.
    • Neustart
  • Von Windows-CD booten, um MBR mit Bootcode für Windows auszustatten
    • In Computerreparaturmodus gehen
    • Windows-Installation auswählen und dann Kommandozeile auswählen
    • bootrec.exe /FixMbr eingeben, „repariert“ Windows -7-Boot-Code im MBR
    • Neustart
  • An Startbildschirm:
  • Mit gedückter Optionstaste sollte Refit und die Recovery-Partition, evtl. noch Windows zu sehen sein
  • Unter Refit sollte Mac OS, Windows und Linux zu sehen sein und auch alles damit zu starten gehen.

Problembehebungen:

Wenn etwas nicht so läuft, wie es soll (würde mich nicht wundern), dann sind folgende wesentlichen Punkte zu kontrollieren oder zu wiederholen:

1. Die Partitionstabelle ist und Mac OS mit dem Festplattendienstprogramm oder und Linux mit gdisk oder gparted lesbar. Sie sollte stimmen, sonst lieber noch mal von vorne anfangen.

2. Stimmen die Partitionen, kann man den Hybrid-MBR jederzeit wieder neu erzeugen lassen wie oben beschrieben.

3. Grub muss in eine Partition und diese Partition wiederum muss im Hybrid-MBR auftauchen, auch wenn grub-setup sich ziert (deshalb -f für FORCE)

4. Den Windows-Bootloader kann man jederzeit von der Installations-CD aus reparieren und damit den MBR anpassen.

5. Bei mir war es auch möglich, aus der Grub-Bootliste Windows 7 auszuwählen und zu starten. Wenn man damit zufrieden ist, kann man Grub im MBR lassen und braucht nichts mehr mit grub-setup und bootrec.exe zu korrigieren. Das vereinfacht also die Installation.

Ergänzung:

– Beim Systemupgrade von Ubuntu 11.10 auf 12.04 sollte zunächst alle 11.10-Updates eingespielt werden, dann beim Upgradevorgang (wenn die entsprechende Frage kommt) die Netzwerkkonfiguration neu gesetzt werden, der Bootloader in eine Partition installiert werden (nicht in den MBR der Platte).