© Matthias Meier 2022
© Manuel Di Cerbo 2025

Samba File Server #

Samba ist die ideale Lösung, wenn Sie Zuhause oder im Office einen File-Server einrichten möchten, auf den Sie mit Windows, Mac, Linux oder mobilen Geräten (Smartphone, Tablet, etc.) zugreifen können, ganz ohne Lizenzkosten und auf dem Raspi mit relativ tiefem Energieaufwand.

Samba Server #

Die Client-Seite von „Samba“ kennen Sie ja schon aus dem ersten Versuch – mit dieser kann unter Linux auf Windows-Freigaben zugegriffen werden, was bekanntlich wie folgt möglich ist^[1]:

• Entweder über den Linux-Dateimanager (z.B. nautilus) nach Anzeige der Adresszeile (per Ctrl-L) durch Eingabe in der Form von: smb://server-name/freigabe-name (wonach bei erfolgreicher Verbindung zwecks bequemem Wiederverbinden ein „Lesezeichens“ angelegt werden kann...)
• Oder per „mounten“ der Freigabe an eine beliebige Stelle in den Verzeichnisbaum (vergleichbar mit dem Virtualbox Shared Folder), entweder manuell (per mount -t smbfs ... resp. mount -t cifs … ) oder mittels Eintrag in der Datei /etc/fstab welche automatisch beim Booten eingelesen wird^[2].

In diesem Versuch werden Sie sich der Serverseite von Samba zuwenden, welche (da Samba freie Opensource ist) kostenlos, zuverlässig und schlank daherkommt und in jeder anständigen Linux-Distribution über den Packetmanager nachinstallierbar ist. Mit etwas Linux-Kenntnisse (abgesehen von ein paar Stolperfallen) ist Samba recht einfach zu konfigurieren. Samba (und Linux) wird auch in allen NAS-Servern (Network Accessed Storage) verwendet, wie z.B. den Synology NAS^[3].

Im Folgenden konfigurieren Sie Samba aber selbst von der Pike auf direkt auf dem „Raspi“...

Loggen Sie sich entweder per SSH auf Ihrem Raspi ein (unter Linux/OS-X also per ssh oder aus Windows per putty . Tipp: vorgängig mit Hostsystem und Raspi dem gleichen Hotspot beitreten – als Loginname haben Sie auf dem Raspi pi definiert) … und installieren Sie auf dem Raspi das Package samba. (Die Frage betr. WINS beantworten Sie mit <No>) Welcher Samba-Release wurde installiert? (eruierbar per samba --version oder smbd --version):

Im unserem Testszenario verwenden wir deshalb nicht unser Linux-Gastsystem sondern das Raspi als Samba-Server. Alle nachfolgenden Linux-Commands geben Sie also auf der Raspi-Console über eine ssh-Verbindung (also via putty.exe oder auf OS-X oder Linux per ssh) ein!

Das Raspi sollten Sie per SSH über dessen eindeutingen Hostname raspberrypi-XX erreichen (oder falls dies nicht klappt mit Anhängen von .local also raspberrypi-XX.local per mDNS).

Sofern auch dies nicht klappt, verwenden Sie die IP-Adresse, welche Sie z.B. mittels der Handy App "Fing" oder über die asynchron serielle Console eruieren.

Verifizieren sie auf dem Windows-Client, wie der "Arbeitsgruppenname" ihres Windows-Systems lautet (eruierbar auf Windows 10) per: (Maus-Rechts) Start → System → [Suchen] nach "Arbeitsgruppe". Arbeitsgruppenname:

Samba Konfigurationsdatei smb.conf #

Der Samba-Server wird in einer einzigen Datei konfiguriert: /etc/samba/smb.conf

Die installierte Original-Datei ist mit sehr viel Kommentar überladen weshalb wir diese wie folgt „retten“ und mit einer leeren Konfigurationsdatei beginnen:

cd /etc/samba
sudo mv smb.conf smb.conf.orig
sudo nano /etc/samba/smb.conf

Wenn das Umbenennen funktioniert hat, öffnet sich eine leere Datei.

Die Grundstruktur von smb.conf ist einfach: unter in eckigen Klammern angegebenen [Abschnitten] werden Einstellungen in der Form option = wert angegeben.

Detaillierte Erklärungen zu den Optionen finden Sie per: man smb.conf oder viele Beispiele in der geretteten Original-Datei smb.conf.orig.

Unter Abschnitt [global] werden demzufolge die generellen Server-Einstellungen definiert:

• Erstellen Sie folgenden Abschnitt wobei Sie statt „Arbeitsgruppenname“ jener Ihres Windows-Clients angeben:
  txt

  [global]
      workgroup = der oben ermittelte Arbeitsgruppenname
      dns proxy = no
  

Der nach aussen sichtbare Name des Samba-Servers (im Windows Jargon „netbios name“) heisst standardmässig gleich wie der Hostname des Linux-Rechners (vgl. Kommando hostname,) also:

• Standardmässig wird als "Netbios name" (also als Servername) der Hostname welcher unter /etc/hostname definiert ist verwendet. Diesen haben Sie ja auf einen eindeutingen Namen raspberrypi-XX geändert.
  Dieser "Netbios Name" könnte unter [global] mittels einem Eintrag netbios name = was-auch-immer umdefiniert werden, was Sie aber besser unterlassen, d.h. falls Innen der Name raspberrypi-XX nicht gefällt, ändern Sie besser den Hostnamen via Ändern von /etc/hostname und booten das Raspi danach.

  Netbios Name

  Achtung: der netbios name und damit auch der Hostname darf max. 14 Zeichen lang sein und keine Sonderzeichen wie # enthalten!

• Nach diesem minimalistischen [global] Abschnitt können in weiteren Abschnitten noch die gewünschten Netzwerkfreigaben definiert werden: für's erste soll bloss eine Freigabe namens „temp“ eingerichtet werden, welche das Linux-Verzeichnis /tmp freigibt:

  txt

  [temp]
      path = /tmp
  

  tmp vs temp

  Achtung: Der Freigabename ist im Beispiel "temp", der freigegebene Ordner hingegen bloss der im Root-Verzeichnis bereits bestehende Ordner tmp (also ohne e geschrieben!)

• Nach Speichern der Datei prüfen Sie diese Konfiguration /etc/samba/smb.conf auf korrekte Syntax per testparm.

• Worauf Sie dann nochmals die enter-Taste betätigen, erst dann werden auch die Freigaben angezeigt! → Achten Sie sich auf eventuelle Fehlermeldungen!!!

Frage: Welche „Server role“ wurde dabei gemeldet?

Statt nach jeder Änderung neu zu booten, können die beiden Dienste mittels 'systemctl' neu starten^[6]:

sudo systemctl restart smbd
sudo systemctl restart nmbd

• Kontrollieren Sie noch per ps -ef | grep mbd ob die beiden Samba-Prozesse auch wirklich laufen.
• Versuchen Sie nun auf dem Windows-Host auf Ihren Rechner zuzugreifen, per (Maus-Rechts) Start→Ausführen: \\servername\temp (als servername den hostname ihres Raspi angeben!)
• Erscheint bloss eine Fehlermeldung "Auf \servername\temp konnte nicht zugegriffen werden" (oder ähnlich), versuchen Sie es nochmals mit anhängen von .local an den Servernamen also z.B. raspberrypi-XX.local und falls dies auch nicht klappen sollte, mit der IP-Adresse Ihres Raspi statt mit dessen "servername" (vermutlich blockt in diesem Fall der Windows-Firewall die Netbios Broadcasts des nmbd Dienstes oder die DNS-Registrierung.)
• Nach erneutem Versuch sollte nun zumindest ein Anmelde-Dialog nun erscheinen, das Anmelden ist aber immer noch nicht möglich… (s. nächster Abschnitt)^[7]:

• Überprüfen Sie: standardmässig wird die Freigabe nur zum Lesen freigegeben!

Natürlich kann auch von der Linux Oberfläche auf Windows-kompatible Freigaben zugegriffen werden. Versuchen Sie es aus dem Linux Gastsystem aus dem Dateimanager (nautilus) wobei Sie zuerst per Ctrl-L die Adresszeile anzeigen lassen und dann folgendes eingeben: smb:// servername/temp/ oder gleich mit Angabe Ihrer userid: smb://userid@servername/temp/. Abhängig von der Art der Namensauflösung (via Netbios Broadcast oder via DNS) funktioniert dies nicht sondern nur via IP-Adresse statt dem Hostname. Funktionierte es bei Ihnen über den Hostnamen und wenn ja, welche Art Namensauflösung wurde offensichtlich verwendet?

Freigeben von Home-Verzeichnissen #

Um auf einen Schlag alle existierenden Linux-Homeverzeichnisse freizugeben, ist nur folgender Abschnitt nötig:

[homes]
    valid users = %S
    read only = no
    browseable = no

Damit wird also automatisch das existierende Homeverzeichnisse pi sowie allenfalls alle anderen Homeverzeichnisse auf dem Server unter deren Namen freigegeben – vorausgesetzt, für die weiteren User besteht auch sowohl eine Linux-User-ID als auch ein per smbpasswd erstellter Samba-User samt Passwort!

Obige Angabe von valid users = %S gewährleistet dabei, dass jeder Samba-User nur jeweils auf sein eigenes Home-Verzeichnis, d.h. auf seine eigene Home-Freigabe zugreifen kann (und nicht auf andere).

Eine Angabe von path = ist nicht nötig, denn der Pfad zu den Homeverzeichnissen ermittelt der smbd Daemon aus der Datei /etc/passwd . Vergewissern Sie sich davon mit: cat /etc/passwd Aufgrund von read only = no (oder alternativ per writable = yes ) ist auch ein Schreibzugriff möglich!

Die Option browseable = no dient (ein wenig) der Sicherheit: dadurch werden die „homes“-Freigaben versteckt und sind auf Ebene \\server nicht gleich für alle sichtbar!

Erstellen eines User-Accounts ohne Login-Rechte #

Oft sollen Samba-User zwar Zugriffsrechte auf Samba-Freigaben haben, jedoch kein Linux-Login-Recht auf dem Server selbst. Für derartige User sind nebst Samba-Useraccounts und zugehörige Samba-Passworte trotzdem Linux-Useraccounts nötig, jedoch mit gesperrtem Linux-Passwort sowie einer Shell-Angabe von /bin/false in /etc/passwd, wodurch sich der User eben nicht direkt am System anmelden kann (auch nicht via ssh).

Das Erstellen derartiger Useraccounts geschieht gemäss den man-Pages useradd und smbpasswd per

# Erstellt Linux-User inkl. Homeverzeichnis und ohne Login-Shell
sudo useradd -m -s /bin/false username
# Erstellt den Samba-User (mit interaktiver Passwortangabe)
sudo smbpasswd -a username

Erstellen Sie auf diese Weise einen User „testuser“ und testen Sie...

Ein Windows Client lässt aber gleichzeitig nicht mehrere User zu einem SMB-Server zu. Beim Testen mit mehreren User-Accounts ab dem gleichen Windows-Client tritt folglich ein Problem auf, weil der Windows-Client geöffnete Freigaben selbst dann offen hält, wenn das Explorer-Fenster geschlossen wird.

Überprüfen Sie dies in einer Window-Commando-Console (nach Start > Ausführen: cmd) mittels:

net use

Somit kann kein anderer Username angegeben werden solange man sich nicht bei Windows abmeldet - daran ändert auch ein Neustart des Samba-Daemons nichts!

Statt sich aber jedesmal mühsam erst ab- und anzumeden, kann die Verbindung zur Freigabe auch wie folgt in einer Windows cmd-Shell getrennt werden:

net use \\servername\freigabename /d

oder gleich alle vorhandenen Serververbindungen trennen: (Achtung: auch jene zum FHNW-AD-Server!)

net use * /d

Gruppenfreigaben #

Generell sollte das Verzeichnis /tmp nicht freigegeben werden, da dieses Verzeichnis einerseits beim Booten meist gelöscht wird, andererseits von einigen Linux-Applikationen für temporäre Dateien verwendet wird. Man richtet Freigaben "für alle" besser auf andere, dedizierte Freigabeverzeichnisse ein.

Wo solche Gruppen-Freigabeverzeichnisse erstellt werden sollen, ist Ansichtssache: einerseits empfiehlt der aktuelle „File Sytem Hierarchy Standard“ Server-Freigaben unter dem Verzeichnis /srv/ anzulegen, also z.B. unter /srv/samba/public, andererseits spricht auch einiges dafür, derartige Gruppen-Freigabeverzeichnisse unter /home/…, z.B. auf /home/public anzulegen – ohne zugehörigen User-Account!

• Der Ordner würde somit bei einem Backup aller Userdaten (unter /home/...) ebenfalls gesichert.
• Oft wird das Stammverzeichnis /home/ auf eine separate Partition gemountet, womit diese (resp. die Userdaten) bei Neuinstallation des Betriebssystems erhalten bleiben kann (und damit auch das oben definierte Gruppenfreigabeverzeichnis). Auch bei einem Ausfall der Systempartition ist dies besser.
• Wenn tatsächlich ein Raspi "produktiv" als Samba-Server eingesetzt werden soll, sind Freigaben auf SD-Karten-Ordner jedoch langsam, voumenbegrenzt und fehleranfällig. Diesbezüglich besser sind Samba-Freigaben, welche auf eine externe, via USB3 angeschlossene HD oder SSD laufen. Beim Raspberry Pi OS Lite werden jedoch nicht wie bei der Desktop Version externe USBDatenträger automatisch gemoutet, weshalb man die externen Diskpartitionen entweder nach jedem Booten wieder manuell mounten muss, oder man trägt diese Partitionen im richtigen Format in /etc/fstab ein, sodass diese beim Booten automatisch gemountet werden. (Als Mountpoint könnte man einen Ordner unter /mnt/… angeben oder gleich als /home mounten, sodass die externen Homeverzeichnisse aufgrund der Samba [homes] Definition automatisch freigegeben würden)^[9].

Ergänzen Sie folgenden Abschnitt in /etc/samba/smb.conf

[public]
    path = /home/public
    read only = no

Natürlich muss das Freigabeverzeichnis /home/public auch noch erstellt werden (per sudo mkdir ...).

• Am einfachsten vergeben Sie also auf dem Freigabeverzeichnis „Schreibrecht für Alle“ z.B. mit:

  bash

  sudo chmod 777 /home/public
  

  Erklärung: Die Angabe 777 oder a=rwx resp. ugo=rwx steht bekanntlich für user=rwx, group=rwx und others=rwx , d.h. sowohl der Eigentümer dieses Verzeichnisses wie auch Mitglieder der auf dem Verzeichnis angegebenen Gruppe wie auch alle Anderen User (others) dürfen den Verzeichnisinhalt lesen, schreiben (oder löschen) sowie das Verzeichnis „betreten“.

  Da das Verzeichnis über sudo erstellt wurde, wird der Verzeichnis-Eigentümer wie auch die Gruppe auf root gesetzt.

Nun können alle Samba-User in die Freigabe public schreiben – vorausgesetzt es existieren für sie sowohl ein Samba- als auch ein Linux-User-Account!

Variante: Gruppenfreigabe ohne gemeinsame Schreibrechte #

Die User können also in entsprechend erstellte Freigaben nur die eigenen Files verändern und auch nur direkt im freigegebenen Ordern („public“) sowie in eigenen Unterverzeichnisse darunter schreiben - dies könnte natürlich gewollt sein:

Jeder User kann sein Unterverzeichnis erstellen und Files darin ablegen, welche anderen Usern zum Lesen zugänglich sind. Eine Unschönheit bliebt trotzdem: da das Verzeichnis public selbst ja für alle User beschreibbar ist, können andere User die Dateien, welche direkt unter public sind löschen!

Variante: Gruppenfreigabe mit gegenseitigem Änderungsrecht #

Sollte auch ein Ändern von Files aller anderen User möglich sein, muss Samba angewiesen werden, dass auf der betreffenden Freigabe die File-Permissions für neu erstellte Files auf group=rw- resp. others=rw- sowie bei neu erstellte Unterverzeichnisse auf group=rwx und others=rwx erstellt werden. Dies ist über zwei weitere Freigabe-Optionen einfach möglich:

[public]
    path = /home/public
    read only = no
    create mask = 0666
    directory mask = 777

Zugriffsbegrenzung auf User-Ebene: #

Sollen nicht alle User sondern nur ausgewählte User Schreibrecht auf eine Gruppenfreigabe erhalten, könnte an stelle von read only = no wie folgt nur den namentlich erwähnten Usern Schreibberechtigung gegeben werden:

write list = UserA UserB ...

Mit der Option valid users könnte weiter auch eine Einschränkung der leseberechtigten User erfolgen:

valid users = UserA UserB UserC UserD ...

Sofern die Anzahl User gross ist, wird dies unpraktisch. In diesem Fall wäre es komfortabler, statt die User einzeln in smb.conf aufzuführen, eine entsprechende Linux-Gruppe zu erstellen, z.B. pubwriter für die Schreibberechtigten und pubreader für die Leseberechtigten. Die Erstellung der Gruppen und Aufnahme der User könnte z.b. wie folgt geschehen:

# neue Gruppen erstellen...
sudo groupadd pubwriter 
sudo groupadd pubreader

# gewünschte User diesen Gruppen zufügen...
sudo usermod -a -G pubwriter UserA 
sudo usermod -a -G pubwriter UserB
sudo usermod -a -G pubreader UserC
sudo usermod -a -G pubreader UserD

Danach können diese Unix-Gruppen in smb.conf verwendet werden:

[public]
    ...
    write list = @pubwriter
    valid users = @pubwriter @pubreader
    ...

Beachten Sie, dass die gesamte Rechte-Prüfung immer noch durch den Samba-Daemon geschieht, denn auf Filesystem-Ebene haben ja alle Files dieser Freigabe imm noch Permission 666 resp. die Verzeichnisse 777 Die Users aus pubreaders dürften sich also nicht direkt auf dem System oder per SSH einloggen können sonst wäre die Sicherheit im Freigabeordner kompromitiert! Einen Lösungsansatz für dieses Problem ist unter Fussnote^[11].

Zugriff auf Interface- und IP-Ebene einschränken #

Möchte man den Samba-Server auf Interface- oder IP-Ebene einschränken, sodass smbd die Freigaben nur auf bestimmten IP-Adressen oder -Adressbereiche zulässt, könnte dies unter Abschnitt [global] über die Einträge „interfaces“ sowie „bind interfaces only“ geschehen, wie folgendes Beispiel zeigt:

[global]
    ...
    interfaces = eth0 lo
    bind interfaces only = yes
    ...

Damit würde der Samba-Dienst auf das Interface eth0 eingeschränkt und Zugriffe z.B. vom WLANInterface verhindern^[12].

Printer-Freigaben #

Samba kann nicht nur Verzeichnisse freigeben, sondern auch die auf dem Serversystem installierten Printer-Queues. Dabei leitet Samba die Printjobs einfach weiter zum vorhandenen Linux PrinterSubsystem, wobei diverse unterstützt würden. Gängig auf aktuellen Linux (und Apple OS-X) Systemen ist das Printsystem CUPS (Common Unix Printing System).

Da Windows-Clients die Printjobs auf dem Client-Rechner selbst formatieren, müssen im Problemfall die auf dem Samba-Server definierter Drucker nochmals als Raw-Printer (d.h. ohne Formatierung auf dem Samba-Printserver) definiert und freigegeben werden! Sogar die Windows-Druckertreiber könnten auf den Samba-Server hochgeladen werden, sodass ein Windows-Client diesen beim ersten Verbinden mit dem Drucker automatisch installiert (vgl. smb.conf.ori )

Alternativ kann ein Windows-Client aber auch direkt auf einen CUPS Printerserver drucken. Microsoft bezeichnet dieses Protokoll als IPP, resp. IPPS (Internet Printing Protocol Subsystem). Damit CUPS lokale Printer auch extern freigibt, müsste in /etc/cups/cupsd.conf noch die entsprechenden Zugriff gewährt werden...^[13]

Schlussbemerkungen #

Wird beim Zugriff auf einen Samba-Server auch Client-seitig ein Linux-System verwendet und die Freigaben auf dem Client-System direkt in den Verzeichnisbaum gemountet (per manuellem mount oder via /etc/fstab), wendet Samba automatisch die „Samba Unix-Extensions“ an. Diese „Unix-Extension“ unterstützen auch die unter Linux oft verwendeten symbolischen Links (Symlinks) sowie die Linux Permissions.

An Stelle von Samba wurde früher im POSIX-kompatiblen Umfeld (und damit auch im LinuxUmfeld) vorwiegend NFS zur Dateifreigabe resp. als „Remote-Filesystem“ verwendet. NFS ist in der Grundkonfiguration zwar sehr einfach zu konfigurieren und ein sehr effizientes Protokoll, beinhaltet jedoch in der Grundkonfiguration keine Benutzer-Authentifikation, weshalb NFS in der Grundkonfiguration sicherheitstechnisch äusserst bedenklich ist und nur in isolierten sicheren Bereichen (wie z.B. zuhause) verwendet werden sollte, also keinesfalls über's Internet oder an unsicheren LANs wie hier an einer Schule oder in einem Firmen-LAN!

Nur unter Verwendung neuerer NFS-Versionen (wie NFS4 mit Kerberos) ist eine sichere Authentifikation via „Kerberos“ Protokoll gewährleistet. Eine derartige Installation ist aber bei den meisten Distributionen recht aufwändig – deutlich aufwändiger als eine sichere SambaKonfiguration.

Will man eine Dateifreigabe aus resp. über das Internet zugänglich machen, sollte man aus Sicherheitsgründen weder Samba- und schon gar nicht NFS direkt "nach Aussen" zugänglich machen!

Soll es wirklich SMB oder NFS über's Internet zugänglich sein, verwendet man am Besten einen VPN Tunnel )(wireguard z.B.). Bei der FHNW sind die Dateifreigabenvon Extern ja auch nur via VPN zugänglich. Die Meisten NAT-Router haben eine VPN-Router Funktionalität, welche sich einfach aktivieren lässt.

Die andere Variante ist SSH welches die gleiche Sicherheit bietet wie ein VPN: Ein SSH-Server bietet nebst einer sicheren Consoleverbindung ja bekanntlich auch die Möglichkeit, einzelne Dateien oder auch ganze Verzeichnisse einfach und sicher mittels scp oder sftp zwischen Linuxresp. Unix-ähnlichen Systemen transferiert werden.

Dies klappt sogar ab der grafischen Oberfläche aus dem Linux Dateimanager nautilus (in der Form: sftp://user@host/ ) oder von und zu Windows-Clients unter Verwendung von „WinScp“. Um Angriffe auf den SSH-Port zu vermeiden, definiert man am Besten den SSH-Serverport von default 22 auf einen "krummen" Wert im Bereich zwischen 10'000 … 60'000 um. Das bietet keinen ultimativen Schutz, trennt einen aber von sehr primitiven Angriffen ohne Portscan.

Alternativ eigenen sich für Dateifreigabe aus dem Internet natürlich auch Cloud-Lösungen wie Dropbox oder Microsofts Sharepoint etc. Eine eigene Cloudlösung werden Sie dann im nächsten Versuch kennen lernen (Nextcloud)...