Immer mehr macOS-Clients schleichen sich in die Unternehmensnetzwerke, die einst exklusiv von Windows-PCs bevölkert waren. Doch dabei sprechen nicht alle die gleiche Sprache. Es helfen ein paar Modifikationen an den Samba-Servern, um die Koexistenz von macOS und Windows zu vereinfachen. Zudem offeriert Samba für Apple-Maschinen weitere Funktionen, die es auf Windows gar nicht gibt. In diesem Workshop stellen wir einige Konfigurationen und Tricks für Samba-Server vor, die besondere Funktionen für macOS im LAN bereitstellen.
Seit der Einführung des iPhone im Jahr 2007 ging es für Apple steil bergauf. War die Apple-Aktie vor 2005 noch ein Penny-Stock mit einem Wert von unter einem US-Dollar, hat sich das Unternehmen in der Zwischenzeit zum zweitgrößten Konzern neben Microsoft entwickelt, dessen Marktwert bei knapp drei Billionen US-Dollar liegt. In den frühen 2000ern waren Apple-Desktops noch Nischencomputer für spezielle Einsatzgebiete wie Desktop-Publishing. Auch das hat sich geändert und heute gehört Apple neben HP, Lenovo und Dell zu den vier größten PC- und Notebook-Herstellern mit einem Marktanteil von rund neun Prozent. Besonders die Apple-Notebooks finden sich immer häufiger in den Aktenkoffern der Geschäftsanwender. Selbst IBM als der ursprüngliche Erfinder des PCs stattet seine Mitarbeiter in der Zwischenzeit mit MacBooks als Arbeitsgerät aus.
Zum Glück verwenden die modernen Macs zur Netzwerkkommunikation keine proprietären Netzwerkprotokolle wie AppleTalk oder das Apple-File-Protokoll mehr, sondern beherrschen offene Standards wie SMB/CIFS, auch wenn sie dem SMB-Stack das ein oder andere AFP-Kommando unterjubeln. Daher verhält sich ein Mac im Unternehmens-LAN ein wenig anders als die Windows- oder Linux-Desktops, mit denen er Dateien austauschen soll. Wer im Netzwerk Linux-Systeme als Fileserver einsetzt, kann sich hier entspannt zurücklehnen. Für Samba 4.x als den populärsten Dateiserver gibt es eine Reihe von Erweiterungen, die es macOS-Clients im LAN bequem machen, den Dateiaustausch mit Windows- und Linux-Clients vereinfachen und Apples Time-Machine-Backup auf dem SMB-Server erlauben.
Auf der Suchenach dem Dateiserver
Die ersten Probleme mit einem macOS-Device im Netzwerk beginnen bereits bei der Suche nach dem Fileserver. Cifs-Server wie Samba setzen eine Reihe von Protokollen wie WINS oder WSDD ein (siehe Kasten "Web Service Dynamic Discovery"), um deren Dienste im LAN zu bewerben. Windows-Clients mit AD-Anbindung finden ihre Fileserver in der Regel über DNS-Einträge und das Active Directory (AD).
Seit der Einführung des iPhone im Jahr 2007 ging es für Apple steil bergauf. War die Apple-Aktie vor 2005 noch ein Penny-Stock mit einem Wert von unter einem US-Dollar, hat sich das Unternehmen in der Zwischenzeit zum zweitgrößten Konzern neben Microsoft entwickelt, dessen Marktwert bei knapp drei Billionen US-Dollar liegt. In den frühen 2000ern waren Apple-Desktops noch Nischencomputer für spezielle Einsatzgebiete wie Desktop-Publishing. Auch das hat sich geändert und heute gehört Apple neben HP, Lenovo und Dell zu den vier größten PC- und Notebook-Herstellern mit einem Marktanteil von rund neun Prozent. Besonders die Apple-Notebooks finden sich immer häufiger in den Aktenkoffern der Geschäftsanwender. Selbst IBM als der ursprüngliche Erfinder des PCs stattet seine Mitarbeiter in der Zwischenzeit mit MacBooks als Arbeitsgerät aus.
Zum Glück verwenden die modernen Macs zur Netzwerkkommunikation keine proprietären Netzwerkprotokolle wie AppleTalk oder das Apple-File-Protokoll mehr, sondern beherrschen offene Standards wie SMB/CIFS, auch wenn sie dem SMB-Stack das ein oder andere AFP-Kommando unterjubeln. Daher verhält sich ein Mac im Unternehmens-LAN ein wenig anders als die Windows- oder Linux-Desktops, mit denen er Dateien austauschen soll. Wer im Netzwerk Linux-Systeme als Fileserver einsetzt, kann sich hier entspannt zurücklehnen. Für Samba 4.x als den populärsten Dateiserver gibt es eine Reihe von Erweiterungen, die es macOS-Clients im LAN bequem machen, den Dateiaustausch mit Windows- und Linux-Clients vereinfachen und Apples Time-Machine-Backup auf dem SMB-Server erlauben.
Auf der Suchenach dem Dateiserver
Die ersten Probleme mit einem macOS-Device im Netzwerk beginnen bereits bei der Suche nach dem Fileserver. Cifs-Server wie Samba setzen eine Reihe von Protokollen wie WINS oder WSDD ein (siehe Kasten "Web Service Dynamic Discovery"), um deren Dienste im LAN zu bewerben. Windows-Clients mit AD-Anbindung finden ihre Fileserver in der Regel über DNS-Einträge und das Active Directory (AD).
Mac-Rechner setzen auf einen anderen Dienst. Apple möchte seinen Nutzern den Umgang mit ihrem Rechner so einfach wie möglich gestalten. Dazu gehört auch, dass Geräte Dienste in einem Netzwerk automatisch finden, ohne dass der Benutzer zuvor etwas konfigurieren muss. Dazu setzt macOS einige Funktionen aus dem "Zero Configuration Networking"-Toolset [1] ein. Zeroconf kann Clients theoretisch vollautomatisch einrichten, ohne dass Administratoren einen DNS-Server aufsetzen müssen. Während Zerconf nur sehr selten für die eigentliche IP-Adressierung mit der "Internet Protocol Automatic Configuration" (IPAC beinhaltet IP-Adressen im Bereich 169.254. x.x) zum Einsatz kommt, wird die "DNS Service Discovery" (DNS-SD) recht häufig verwendet. Apples Zeroconf-Implementierung mit DNS-SD heißt "Bonjour" und findet Netzwerkdienste wie Drucker und Fileserver. Auf der Seite des Linux-SMB-Servers gibt es dazu die Open-Source-Zeroconf-Implementierung "Avahi" [2], die verfügbare Dienste anzeigt.
Bild 1: Dank Avahi-Dienst und passender Konfiguration erscheinen die Linux-Samba-Server im Finder des Mac.
Oft reicht es bereits aus, dass ein nicht konfigurierter Avahi-Daemon auf einem Samba-Server läuft. Um es korrekt zu machen, sollten die Anwender aber die passende Dienstkonfiguration hinterlegen und dazu bedarf es einer einzigen Konfigurationsdatei. Sollten Sie Avahi nicht auf ihrem Samba-Server betreiben, installieren Sie es über den Paketmanager ihrer Distribution. Im Falle unseres Red-Hat-EL8-Servers geht das ganz einfach über dnf install avahi -y. Die Konfigurationsfiles für die jeweiligen Dienste finden sich im Verzeichnis" /etc/avahi/services". Dort legen Sie dann eine "samba.service"-Datei mit folgendem Inhalt an:
<!DOCTYPE service-group SYSTEM "avahi-service.dtd">
<service-group>
<name replace-wildcards="yes">%h</name>
<service>
<type>_smb._tcp</type>
<port>445</port>
</service>
</service-group>
Dann starten Sie den Avahi-Daemon mit systemctl restart avahi-daemon neu. Im Log oder dem Dienststatus finden Sie anschließend den passenden Eintrag "avahi-daemon[x]: Service ‘xx’ (/services/samba.service) successfully established." Nun finden Ihre macOS-Clients den Samba-Server und zeigen diesen im Finder unter "Locations / Network" an.
Web Service Dynamic Discovery
Ohne Avahi tauchen Ihre Samba-Server nicht im Apple-Finder auf. Ein ähnliches Problem tritt aber auch bei neueren Windows-Clients auf, falls diese und ihre Samba-Server keinen ADS-Dienst verwenden. In diesem Fall brauchen Sie parallel zu Avahi auf Ihren Samba-Server noch einen WSDD-Service, der die verfügbaren Dienste der Maschine über IP-Multicast bewirbt. Installieren Sie auf Ihrem Server das WSDD-Paket, in diesem Beispiel auf einem Red-Hat-EL8-Server
dnf install wsdd -y
Bei Red-Hat- und Fedora-Systemen erwartet der Dienst die Konfiguration in der Datei "/etc/default/wsdd". Dort tragen Sie das Interface ein, auf dem Sie die Dienste publizieren wollen, und den Namen des Systems, beispielsweise:
WSDD_PARAMS="-i br0 -n MICRO"
Unser Testsystem verwendet ein Bridge-Network "br0" auf dem ersten physischen Adapter. Ohne Brücke lautet der Parameter dann beispielsweise "-i eno1".
Erweiterte Attribute und Streams
Der Funktionsumfang von Netzwerkdateisystemen wie CIFS, NFS oder GlusterFS weicht oft von den Features lokaler Dateisysteme wie NTFS, BTRFS, XFS oder APFS ab. Das betrifft vor allem erweiterte Attribute oder den Umgang mit Daten-Streams. Daher gab es in der Vergangenheit Operationen unter Windows und macOS, die sich nur von einem lokalen, nicht aber von einem Netzwerkdateisystem ausführen ließen. Samba hat daher bereits mit der Version 3 eine Art modulare Übersetzungsschicht in den Protokoll-Stack gepackt: VFS. Diese Virtual-File-System-Module übersetzen oder emulieren Funktionen eines Client-Dateisystems und sichern diese Informationen auf dem Server-Dateisystem. Zu den VFS-Funktionen gehören beispielsweise Zeichensatz-Konvertierungen, erweiterte Attribute, Server-Side-Copies sowie das Stream-Handling.
Im Zusammenhang mit Apple-Clients setzt Samba zwei VFS-Erweiterungen ein: "streams_xattr" für Datei-Streams. Diese benötigen Sie im Übrigen auch für Win-dows-11-Clients, wenn diese mit dem Edge-Browser Downloads direkt auf eine SMB-Freigabe sichern sollen. Der zweite VFS-Treiber widmet sich den Apple-Erweiterungen im SMB-Protokoll und dem AFPS-Dateisystem und heißt "Fruit". Wichtig dabei ist, dass Sie auf Ihrem Samba-Server beide Erweiterungen in der korrekten Reihenfolge laden. Im globalen Teil der smb.conf-Datei steht dann also:
[Global]
vfs objects = fruit streams_xattr
Daneben muss der Samba-Server erweiterte Attribute unterstützen, weshalb "ea support = yes" notwendig ist. Die meisten Einstellungen des Fruit-Plug-ins legen Sie ebenfalls in den globalen Optionen fest:
fruit:aapl = yes
fruit:metadata = stream
fruit:model = MacSamba
Der "aapl"-Schalter erlaubt, dass der Samba-Server Apples eigene Erweiterungen zum SMB2-Protokoll gestattet. Dass Ihr Server die Protokollversion 2 oder höher verlangt ("min protocol = SMB2"), müsste ohnehin der Standard sein. Der" Metadata"-Schalter gibt an, wie der Samba-Server mit den erweiterten Attributen verfährt. Hier übergibt der VFS-Layer diese Aufgabe an das Stream-Plug-in und somit an "streams_xattr". Das "model" legt eigentlich nur fest, wie das Icon ihres Samba-Servers im Finder erscheint. Es gibt eine Reihe weiterer globaler Optionen, die sie jedoch nicht separat angeben müssen. Hier genügen die Standardvorgaben.
Time Machine auf Samba
Ein besonders beliebtes Feature unter Mac-Anwendern ist das Time-Machine-Backup. In der Regel erfordert das jedoch eine dezidierte Platte oder Partition, die sich dabei für keine anderen Daten als die jeweiligen Sicherungen verwenden lässt. Das Fruit-VFS-Plug-in erlaubt es, eine Samba-Freigabe als Backupziel für Time Machine zu verwenden. Auch auf einer Samba-Freigabe sollten Sie Time-Machine-Daten nicht mit herkömmlichen Inhalten mischen, daher empfiehlt sich ein separater Backup-Share. Damit Time Machine reibungslos funktioniert, brauchen Sie eine Freigabe mit folgenden Optionen:
fruit:time machine = yes
durable handles = yes
kernel oplocks = no
kernel share modes = no
posix locking = no
Optional können Sie begrenzen, wie viel Kapazität des Netzwerk-Datenträgers Time Machine verwenden darf, zum Beispiel mit "fruit:time machine max size = 1T". Ansonsten könnte das Backup Ihre Serverfestplatte gänzlich mit Time-Machine-Daten füllen.
Bild 2: Samba-Server können Shares als Backupziel für Time Machine bereitstellen. Der Server generiert dabei individuelle Unterverzeichnisse pro Benutzer.
Nur eine Backupfreigabe pro Person
Netzwerk-Shares für Backups haben den Nachteil, dass sie eigentlich keine "Shares" sein sollten. Der Zugriff zum Backup eines Benutzers sollte auf genau diesen beschränkt bleiben. Zum Glück hat Samba hier ein paar Tricks im Ärmel. Sie können eine generische Backupfreigabe erstellen, die alle Nutzer im LAN sehen und auch darauf zugreifen können. In diesem Share finden die Anwender dann aber nur ihre eigenen Daten. Der Trick nutzt zwei Samba-Features: Konfigurationsvariablen und ein Preexec-Skript. In der Regel legt der Administrator für einen Share statische Verzeichnisse und Rechte an, wie beispielsweise:
[backup]
comment = Backup Folder
path=/var/lib/samba/backup
browseable = yes
valid users = @smbusers
writeable = yes
Damit erhalten alle Benutzer, die Mitglied der Gruppe "smbusers" sind, Zugriff auf die Freigabe. Sollen die Nutzer jedoch individuelle Backupverzeichnisse bekommen, sieht die Share-Definition so aus:
[backup]
comment = Backup Folder
path=/var/lib/samba/backup/%U
browseable = yes
valid users = %U
writeable = yes
create mode = 0660
directory mode = 0770
guest ok = no
force group = %U
Jetzt hängen sowohl das Unterverzeichnis als auch die Zugriffsrechte zum Share und dem Verzeichnis vom "angeforderten" Benutzernahmen ab. Die Variable "%U" enthält den Namen, mit dem der Nutzer versucht, Zugriff zum Share zu bekommen, bevor er sich korrekt authentisiert hat. Die Variable "%u" enthält im Gegenzug den Nutzernamen, nachdem er sich authentisiert hat. Das ist später für das Skript von Bedeutung. Unser Beispiel geht davon aus, dass jeder Linux-User auf dem SMB-Server Mitglied einer eigenen primären Gruppe mit demselben Namen wie der Benutzer ist. Das ist bei Linux-Distributionen so üblich.
Wenn Sie eine Backupfreigabe wie angegeben definieren, setzt das allerdings voraus, dass Sie im Vorfeld bereits die individuellen Unterverzeichnisse pro User unter "/var/lib/samba/backup" erstellt haben. Meldet sich ein Benutzer an, der über kein Verzeichnis verfügt, gibt der SMB-Client einen Fehler aus. Ein manuelles Eingreifen ist jedoch nicht nötig, denn Samba verfügt über die Option "preexec". Hier können Sie ein Skript angeben, das läuft, bevor der Nutzer Zugang zum Share bekommt. Das Skript agiert dabei mit den Rechten des Benutzers. Daher gibt es zusätzlich die Option "root preexec", die ein Skript als Superuser startet. Und genau solch ein Skript setzen Sie beim individuellen Backup-Folder ein:
[backup]
root preexec = /etc/samba/gendir.sh %U
comment = Backup Folder
path=/var/lib/samba/backup/%U
Da das Preexec-Skript vor dem eigentlichen Zugriff auf die Freigabe läuft, muss es mit dem Parameter "%U" starten, denn zu diesem Zeitpunkt ist "%u" noch leer und funktioniert daher nicht. Wenn nun also ein Benutzer Zugriff zum Backup-Share anfordert, startet zuerst das Skript ("/etc/samba/gendir.sh") mit dem Benutzernamen als Parameter. Dessen Code erstellt das Benutzer-Unterverzeichnis, falls es noch nicht existiert, und legt die passenden Zugriffsrechte fest:
#!/bin/bash
DIRECTORY=/var/lib/samba/backup/$1
if [ ! -d $DIRECTORY ]; then
mkdir -p $DIRECTORY
chown $1:$1 $DIRECTORY
fi
So landet schließlich jeder Benutzer in seinem eigenen Backupverzeichnis, wenn er auf die Samba-Freigabe "backup" zugreift. Vollständig sieht der Time-Machine-Share dann auf Ihrem Samba-Server in etwa so aus wie in Listing 1.
Listing 1: Time-Machine-Share
[backup]
root preexec = /etc/samba/gendir.sh %U
fruit:time machine = yes
fruit:time machine max size = 1T
comment = Backup Folder
path=/var/lib/samba/backup/%U
browseable = yes
valid users = %U
writeable = yes
create mode = 0660
directory mode = 0770
guest ok = no
force group = %U
durable handles = yes
kernel oplocks = no
kernel share modes = no
posix locking = no
Haben Sie viele Mac-Clients im LAN, die alle Daten via Time Machine sichern, können Sie natürlich die Plattenauslastung ihres Backupservers erheblich optimieren, indem sie den Share auf einem Datenträger mit VDO-Deduplikation legen [3].
Inhalte indizieren
Mit Spotlight offeriert macOS einen Dienst, der Dateien nebst Inhalt indiziert. So können Mac-Nutzer im Finder nach Schlagworten suchen und erhalten in der Ergebnisliste alle Dateien, in deren Inhalt das gesuchte Schlagwort vorkommt. Spotlight erfasst aber nur Dateien, die auf dem lokalen Datenträger lagern, nicht aber Dokumente auf einem Fileserver.
Allerdings lässt sich dieses Feature auf dem Samba-Server nachrüsten. Zuerst brauchen Sie eine Elasticsearch-Instanz, die die Suchindizes sichert. Vielleicht betreiben Sie bereits eine Elasticsearch- oder Opensearch-Instanz im LAN, um damit Logdaten zu aggregieren. Dann können Sie dort zusätzlich den Index ablegen. Alternativ starten Sie eine simple Single-Node-Instanz in einem Docker- oder Podman-Container direkt auf ihrem Samba-Server. Der global-Sektion der smb.conf-Datei fügen Sie dann die folgende Elasticsearch-Verbindung hinzu und schon steht die Verbindung zwischen Samba und Index-Datenbank:
spotlight backend = elasticsearch
elasticsearch:address = localhost
elasticsearch:port = 9200
Jetzt ist nur noch ein Dienst erforderlich, der Ihre Dateien verschlagwortet und das Ergebnis in die Elasticsearch-Datenbank hochlädt. Am einfachsten geht das ebenfalls mit Hilfe eines Podman- oder Docker-Containers direkt auf dem Samba-Server und dem Open-Source-Tool "FSCrawler" [4]. Dieses durchsucht rekursiv alle Dateien in einem angegebenen Verzeichnis und verschlagwortet diejenigen, deren Format es lesen kann. Zudem kann FSCrawler über das ebenfalls freie Tool "Teseract" [5] aus Bilddateien und PDFs Texte mittels OCR extrahieren und verschlagworten. Das offizielle Docker-Image hat alle dazu nötigen Tools bereits integriert. FSCrawler verwendet so genannte "Jobs", die definieren, wo das Werkzeug was durchsuchen soll und erlauben dem Anwender, verschiedene Parameter für unterschiedliche Verzeichnisse.
In unserem Beispiel starten wir den FSCrawler-Dienst mit root-Rechten in einem Podman-Container. Die Jobkonfigurationen sichern wir dabei im Verzeichnis "/root/fscrawler". Unser erster Job heißt "d1" und indiziert das Datenverzeichnis. Die Konfiguration für diesen Job liegt daher in der Datei "/root/fcsrawler/d1/_settings.yml" (Listing 2).
Listing 2: Konfiguration eines FSCrawler-Jobs
name: "idx"
fs:
url: "/tmp/es"
indexed_chars: 100%
lang_detect: true
continue_on_error: true
ocr:
language: "eng+ger"
enabled: true
pdf_strategy: "ocr_and_text"
elasticsearch:
nodes:
- url: "http://localhost:9200"
ssl_verification: false
Der Crawler soll dabei alle Dateien unterhalb von "/tmp/es" indizieren und das Ergebnis im Index "idx" auf dem lokal laufenden Elasticsearch-Container speichern. Der Aufruf des Podman- Pods lautet dementsprechend:
podman run -it --rm --name FSCrawler \
-v ~/FSCrawler:/root/
.FSCrawler:Z \
-v /var/lib/samba/daten:/tmp/
es:ro \
dadoonet/FSCrawler FSCrawler d1
Der Aufruf blendet den Datenshare auf "/var/lib/samba/daten" im Container als "/tmp/es" ein. Nach dem Indexlauf beendet sich der Container. Je nach Größe des Shares, der Zahl der zu indizierenden Dateien und der CPU-Leistung des Samba-Servers läuft FSCrawler mehrere Stunden. Das ist aber nicht weiter tragisch, denn der Fileserver hat in der Regel ohnehin nicht all zu viel zu tun und kann den Crawler im Hintergrund per Cronjob jede Nacht laufen lassen.
Die Spotlight-Suche auf dem Mac-Client findet jetzt binnen weniger Sekunden alle Dokumente mit dem passenden Inhalt, auch wenn sie auf dem Netzwerk-Share gesichert sind. Dieses Feature ist den vergleichsweise großen Aufwand mit Elasticsearch-Instanz und FSCrawler auf jeden Fall wert. Wichtig ist dabei jedoch, dass Sie die Elasticsearch-Instanz gut absichern und keine Zugriffe von außerhalb des Samba-Servers erlauben.
Bild 3: Die Spotlight-Suche nach "Open Cluster Manager" findet Dokumente auf der Samba-Freigabe, in denen diese Wortkombination vorkommt – neben regulären Textformaten auch PDFs.
Fazit
Mit den Erweiterungen auf den Samba-Servern gliedern sich macOS-Clients perfekt in bestehende Windows-Umgebungen mit Linux-Fileservern ein. Das Time-Machine-Backup via Netzwerkfreigabe funktioniert ebenso gut wie der Austausch von Dateien zwischen Windows- und macOS-Clients. Der absolute Hit ist jedoch die Spotlight-Suche via LAN und Elastic-search. Im Windows-Umfeld bemühen Anwender hier Desktop-Suchmaschinen und müssen damit Netzwerk-Freigaben auf jedem Client individuell indizieren. Die Integration von Spotlight mit Samba und Elasticsearch ist diesen clientbasierten Ansätzen überlegen.