macOS BigSur als NFSv4 client

Ausgehend von der Übersichtsseite über ein kerberisiertes Netzwerk mit NFSv4 als Netzwerkfilesystem klappt die Einbindung auch von neueren macOS Clients prinzipiell.

Der auf BSD basierende Automounter autofs unter macOS funktioniert immer noch. Eine Bespielkonfiguration von /etc/auto_master

#
 Automounter master map
 #
 +auto_master     # Use directory service
 /net             -hosts       -nosuid
 /home             auto_home   -nobrowse,hidefromfinder
 /Network/Servers -fstab
 /-               -static

hat im Gegensatz zu der von Apple ausgelieferten Datei nur in der ersten Zeile das Kommentarzeichen entfernt und ermöglicht somit eine Hostfreigabe unter /net (symlink zu /System/Volumes/Data/net ).
Ein Neustart aufgrund einer autofs Konfigurationsänderung lässt sich übrigens mit

sudo automount -cv 

vermeiden.
Tatsache ist, dass jetzt in der Terminal App der NFS mount erreicht werden kann. Sobald man einen NFS export in den macOS Client eingemounted hat, lassen sich die Dateien gemäß den NFSv4 ACL bearbeiten. Dies gilt bspw. für Terminal Kommandos aber auch das einlesen von Dateien direkt in Programmen geht.

macOS BigSur als NFSv4 client weiterlesen

lifetime von kerberos tickets

Manchmal könnte es passieren, das bspw. der NFSv4 Zugriff nicht mehr klappt, da das authorisierende kerberos ticket nicht mehr gültig ist. Mittels dem Kommando

klist

würde man dann eine Expiration erkennen.

Die grundsätzliche maximale Lebensdauer, sowie die maximale Zeit, in der der Client eine Erneuerung selbstständig durchführen kann, ist serverseitig in der Datei /etc/krb5kdc/kdc.conf festgelegt.

max_life = 1d
max_renewable_life = 14d 0h 0m 0s

wäre ein Beispiel, wobei der zweite Einträg extra die möglichen syntaktischen Möglichkeiten darstellt.

lifetime von kerberos tickets weiterlesen

unliebsame Überraschungen beim NFS Export

Wenn im heimischen LAN IPv4 und IPv6 zum Einsatz kommt, müssen Dienste auch beide Verbindungsarten unterstützen. Gerade bei einem NFS Server wird traditionell in der Datei

/etc/exports

gerne ein IPv4 Subnetz bei den erlaubten Hostzugriffen angegeben. Dies führt aber dazu, dass host-Anfragen mittels IPv6 Verbindungen dann abgelehnt werden, obwohl die IPv4 Adresse des anfragenden hosts für einen Zugriff freigeben wäre. Abhilfe schafft da die Angabe von domain-Namen. Dies wiederum bedingt aber einen funktionierenden DNS der sowohl IPv4 als auch IPv6 Adressen – auch reverse – auflösen kann. Im Falle einer kerberos Sicherung von NFSv4 muss dies aber eh der Fall sein.

hidden files (macOS Finder related) on NFS shares

Zwei Schritte vor – einen zurück. Das beschreibt ungefähr die NFS Unterstützung in macOS.

mit der abermals hier beschriebenen Option:


nfs.client.mount.options = nfc

erzwingt man auf macOS Ebene die Kodierung der Dateinamen als UTF-8 Form C zu interpretieren (machen alle außer Apple so).
Prinzipiell funktioniert das auch, aber der Teufel steckt wie immer im Apfel.

1. Öffnet man eine Form-C relevante Datei, bpsw. mit German-Umlaut „Angebot Sonderwünsche.pdf“ so kann man die Datei auf dem NFS Share auf einem macOS Sierra Client mit Preview öffnen.
2. Leider legt dann Apple Preview (auf deutsch: Vorschau genannt) ein verstecktes File an, in diesem Fall wäre dann eine Datei names „._Angebot Sonderwünsche.pdf“.
3. Sobald diese Datei existiert, kann das eigentliche pdf nicht mehr geöffnet werden, selbst mit Adobe Reader lässt sich die Datei nicht mehr öffnen, obwohl dieser das hidden File gar nicht angelegt hätte.

Die Fehlermeldung selber trägt auch nicht zur Aufklärung bei.
Angebot Sonderwuensche

Leider scheint es unter macOS Sierra auch keine Möglichkeit zu geben, das Anlegen solcher Files auf NFS (oder allg. Network Shares) zu verhindern. Apple ist via Bugreport 32837974 informiert – ob’s was bringt?

NFS auf macOS – typisch Apple

Die Firma Apple ist schlicht und einfach arrogant. Objektiver kann man es nicht ausdrücken.

Jede paar Monate werden Schnittstellen, GUIs und Konfigurationseinstellungen geändert. Alles ohne direkten Nutzen für den Benutzer. Es passt halt ins Konzept der Apple Sekte und wer nicht mindestens die Hälfte seiner privaten Zeit für die phantastischen Neuigkeiten des Apple Universums investiert ist deren nicht würdig.

Eines von unzähligen Beispielen ist der Support für das NFS Protokoll. Damit NFS Client-seitig auf macOS Sierra überhaupt nutzbar ist, müssen Mount Optionen gesetzt werden, was früher mit der GUI NFS mounts in der Applikation Disk Utility möglich war.

Da Apple sein OS allerdings alle paar Monate komplett umkrempelt um in der Design Abteilung keine Langeweile aufkommen zu lassen, gibt es diese Funktionalität nicht mehr. Auf GUI Ebene wählt man nun die GUI Mit Server verbinden in der Applikation Finder an. Ganz easy, ohne lästige Optionen und damit…

…ohne brauchbare Funktionalität. Denn schon seit Jahren ist bekannt, dass Verzeichnisse und Dateien eines NFS mounts im Finder nur dann performant angezeigt werden, wenn die Mount-Option locallocks gesetzt ist.
Um dies auf macOS Sierra zu erreichen, empfielt sich folgendes Vorgehen:

1. in /etc/auto_master den Eintrag /net in der 3.Spalte mit der Option nolocks zu versehen, bspw.
/net -hosts -nosuid,nolocks,locallocks
ACHTUNG: Die Optionen hidefromfinder und nobrowse dürfen nicht gesetzt sein.
2. in /etc/autofs.conf den Eintrag AUTOMOUNTD_MNTOPTS ebenso mit den Optionen nolocks,locallocks versehen.
3. Im Finder erscheint dann unter dem linksseitigen Hostnamen nun auch der Folder net, der allerdings bis dato leer sein dürfte.
4. Dann muss man im Terminal den NFS Share explizit einmal anwählen, bspw. mit
cd /net//
5. Danach erscheint der NFS Share auch im Finder unter net. Diese Gelegenheit benützt man um den Folder auf die linksseitige Favoritenleiste zu legen.

Und das war’s dann….noch nicht ganz. Um die Kompatibilität zu einem Linux-basierendem NFS Server zu gewährleisten (siehe hier und hier) sollte weiterhin Clientseitig auf macOS die mount_nfs Option nfc gesetzt sein, zusammen mit intr um eine Abbruchsignal bei hängendem NFS Server wirksam werden zu lassen, die Datei /etc/nfs.conf würde also folgendermaßen aussehen:

#
# nfs.conf: the NFS configuration file
#
nfs.client.mount.options = intr,nfc

Falls man sich im laufenden Betrieb nicht mehr sicher ist, welche NFS Mount Optionen eigentlich gesetzt sind, befragt man den Client am besten mit

nfsstat -m

Dann sollte dem NFS Client Glück nichts mehr im Wege stehen, oder etwa doch…?