[[Vorlage(Getestet, bionic)]] {{{#!vorlage Wissen [:Pakete_installieren: Installation von Programmen] [:Terminal: Ein Terminal öffnen] [:Editor: Einen Editor öffnen] [:fstab:] }}} [[Inhaltsverzeichnis(2)]] [[Bild(Wiki/Icons/service.png, 48, align=left)]] [wikipedia:Network_File_System:NFS] (Network File System) ist ein stabiles und gut funktionierendes Netzwerk-Protokoll von Sun, um Dateien über das lokale Netzwerk auszutauschen. Prinzipiell würde es auch über das Internet funktionieren, was aber aus Sicherheitsgründen nicht zu empfehlen ist. NFS ist im Prinzip das *NIX-Pendant zu [:Samba:SMB] aus der Windows-Welt. Dieser Artikel beschäftigt sich hauptsächlich mit den veralteten NFS-Versionen 2 und 3. Einen separaten Artikel zur aktuellen Version 4 gibt es hier: [:NFSv4:] = Einsatzszenario = NFS setzt für einen reibungslosen und sicheren Betrieb voraus, dass 1. alle Benutzer im Netzwerk eindeutige [:Benutzer_und_Gruppen#Nummerierung-der-UID-GID:UIDs] haben und 1. alle Rechner im Netzwerk zentral administriert werden Die Rechner müssen also so konfiguriert werden, dass jeder Benutzer netzweit seine eigene feste, numerische UID erhält, die auf allen Rechnern dann gleich ist. Bei größeren Netzwerken stellt man das mit einem [wikipedia:Lightweight_Directory_Access_Protocol:LDAP]- oder [wikipedia:Network_Information_Service:NIS]-Server sicher. Die Zugriffskontrolle auf die einzelnen Dateien geschieht dann auf dem Server über das reguläre Dateiberechtigungssystem. Wenn die Benutzer Root-Rechte auf ihren eigenen Rechnern haben bzw. ihre eigenen Notebooks ins Netz einbinden dürfen, können sie das aber umgehen und sich auf ihren Rechnern beliebige UIDs besorgen, die vom NFS-Server auch nicht weiter getestet werden. In diesem Fall muss dann entweder ein zusätzliches Sicherheitsprotokoll wie [:Kerberos/NFS_mit_Kerberos_sichern: Kerberos] (erst ab [:NFSv4:] möglich) zum Einsatz kommen (nicht-trivial), oder [:Samba:] benutzt werden (langsamer). = Installation = Sollte NFS noch nicht vorhanden sein, lässt es sich sehr schnell installieren. Folgende Pakete und deren Abhängigkeiten müssen über die Paketverwaltung [1] installiert werden: Wenn der Rechner als Server dienen soll, der Dateien bereitstellt: {{{#!vorlage Paketinstallation nfs-kernel-server }}} Wenn der Rechner nur als Client agieren soll, der auf andere Freigaben zugreift: {{{#!vorlage Paketinstallation nfs-common }}} = Freigaben = Die Freigaben von Verzeichnissen und Dateien auf dem Server lassen sich durch direkte Bearbeitung der Datei '''/etc/exports''' verwalten. Dazu muss diese Datei angelegt und/oder bearbeitet werden [3]. Die Freigabe eines Verzeichnisses lässt sich mit einer Zeile nach folgendem Muster anlegen: {{{ PFAD RECHNERADRESSE(OPTIONEN) }}} Leerzeichen sind nur zur Trennung der Felder erlaubt. Wenn man einen Ordner, dessen Name Leerzeichen oder andere problematische Sonderzeichen enthält, freigeben möchte, dann sollte man diese mit doppelten Anführungszeichen (`"`) quotieren. Man kann solche Zeichen auch mit dem umgekehrten Schrägstrich und der Ordnungszahl in dreistelliger oktaler Schreibweise angeben, z.B. Leerzeichen als `\040`. Das Feld `RECHNERADRESSE(OPTIONEN)` zur Beschreibung des Klienten kann mehrfach erscheinen. Hier sind einige Beispiele: {{{ # freigabe1 wird für zwei Rechner freigegeben # notebook darf nur lesen (ro) # desktop darf lesen und schreiben (rw) /PFAD/ZUR/FREIGABE1 notebook(ro,async) desktop(rw,async) }}} Alternativ kann die IP-Adresse angegeben werden: {{{ # Freigabe gilt nur für 192.168.1.13, jedoch nur mit Leserechten: /PFAD/ZUR/FREIGABE2 192.168.1.13(ro,async) # Freigabe gilt für alle IPs von 192.168.1.1 bis 192.168.1.255, mit Lese-/Schreibrechten: /PFAD/ZUR/FREIGABE3 192.168.1.0/255.255.255.0(rw,async) # Freigabe gilt nur für den Rechner mit dem Namen notebook "/PFAD/ZUR/FREIGABE 4" notebook(ro,async) }}} {{{#!vorlage Warnung Als Rechneradresse kann neben einer IP-Adresse oder eines IP-Bereiches auch ein Rechnername oder ein DNS-Domainname angegeben werden. Allerdings müssen im Gegensatz zu IP-Adressangaben diese Namen bereits beim Systemboot richtig aufgelöst werden können, was nicht immer der Fall sein muss. Kann der Name beim Booten nicht aufgelöst werden, wird die Freigabe nicht erstellt. Dies kann zu erheblichen Problemen führen. }}} Die Parameter in den Klammern lauten: {{{#!vorlage Tabelle Optionen in der /etc/exports +++ Option Beschreibung default +++ `rw` Lesen und Schreiben - +++ `ro` nur Lesen X +++ `sync` Synchroner Datentransfer X* +++ `async` Asynchroner Datentransfer. In der Regel führt diese Option zu einer Leistungsverbesserung auf Kosten möglicher Datenverluste durch Server-Abstürze bzw. Neustarts. Bis nfs-utils 1.0.0 war die Option 'async' standardmäßig aktiviert. -* +++ `wdelay` Diese Option hat nur im Zusammenhang mit 'sync' einen Effekt, siehe 'no_wdelay'. X +++ `no_wdelay` Diese Option hat nur im Zusammenhang mit 'sync' einen Effekt. Ein NFS-Server würde normalerweise einen Schreibzugriff auf die Platte etwas verschieben, wenn er davon ausgeht, dass ein anderer, verwandter Schreibzugriff gerade oder bald ankommt. Das ermöglicht es, mehrere Schreibzugriffe in einem Abwasch zu erledigen, was den Durchsatz erhöhen kann. Wenn ein NFS-Server hauptsächlich kleine und nicht zusammengehörige Schreibaufträge erhält, kann dieses Verfahren aber stören und die Leistung verringern. Für diesen Fall ist die Option gedacht, um es auszuschalten. Standardmäßig ist 'wdelay' aktiviert. - +++ `secure` Ports oberhalb 1024 nicht verwenden. X +++ `insecure` Ports oberhalb 1024 auch verwenden. - +++ `hide` "Platzhalter" X +++ `nohide` Wenn unterhalb eines exportierten Verzeichnisses (z.B. '''/home/user''' auf '''/dev/hda1''') ein weiteres Dateisystem eingebunden wurde (z.B. '''/dev/hdb1''' in '''/home/user/Musik'''), so wird dieses Verzeichnis durch einen eigenen exports-Eintrag exportiert. Im Normalfall (Option `hide`) sieht der Client dieses Unterverzeichnis nicht, wenn er nur das Oberverzeichnis einbindet, weswegen er beide einbinden muss. Durch die Option `nohide` (im Export des übergeordneten Verzeichnisses) werden die eingebundenen Unterverzeichnisse dem Client nicht mehr als eigene Partitionen präsentiert, sondern als normale, zum Oberverzeichnis gehörende Verzeichnisse. Daher muss man zwar am Server noch alles explizit exportieren, am Client aber nur noch das übergeordnete Verzeichnis einbinden. Die Option `nohide` funktioniert nur, wenn die Client-Angabe ein festgelegter Rechner ist. Bei Wildcards oder ganzen IP-Bereichen klappt das nicht, dort könnte die Option `crossmnt` zum gewünschten Erfolg führen. - +++ `crossmnt` Diese Option ist so ähnlich wie `nohide`. Die Option `crossmnt` ermöglicht es, dass Clients auf exportierte Dateisysteme innerhalb der Freigabe zugreifen können. Wenn ein Kind-Dateisystem "B" auf einem übergeordneten "A" aktiviert ("mount") wird, hat die Einstellung `crossmnt` auf "A" den gleichen Effekt wie die Einstellung `nohide` auf B. Wie bei `nohide` muss auch hier jedes Kind-Dateisystem "B" explizit exportiert werden. - +++ `subtree_check` Wenn nur einzelne Verzeichnisse eines Dateisystems freigegeben wurden, wird hiermit überprüft, ob eine vom Client angeforderte Datei in diesen Verzeichnissen des Dateisystems ist. Wurde das gesamte Dateisystem freigegeben, werden die Übertragungsgeschwindigkeiten beim Deaktivieren mittels `no_subtree_check` erhöht. Darüber hinaus stellt diese Option sicher, dass beim Einbinden eines NFS-Verzeichnisses mittels 'root_squash' alle Dateien, die dem user 'root' gehören, nicht abrufbar sind (selbst wenn die Datei-Rechte dies vorsehen).[[BR]] Diese Option kann jedoch Probleme verursachen, insbesondere wenn Dateien umbenannt werden, die auf dem Client gerade geöffnet sind. -* +++ `no_subtree_check` Diese Option schaltet die Überprüfung von Unterverzeichnisbäumen ab. Das hat zwar eine leichte Verringerung der Sicherheit zur Folge, kann aber die Verlässlichkeit unter Umständen erhöhen. Wenn ein Unterverzeichnis eines Dateisystems freigegeben (exportiert) wird, aber das ganze Dateisystem nicht, muss der NFS Server jedesmal, wenn er eine Anfrage bekommt, nicht nur überprüfen, ob die gewünschte Datei in dem Dateisystem liegt (einfach), sondern auch, ob sie tatsächlich in dem Unterverzeichnis liegt (schwieriger). Diese Überprüfung wird "subtree_check" genannt. Um diese Überprüfung durchzuführen, muss der Server einige Informationen über die Position der Datei im Dateisystem im Datei-Objekt ("file handle") integrieren, die an den Client weitergegeben wird. Das kann zu Problemen beim Zugriff auf Dateien führen, die umbenannt werden, während sie noch von einem Client geöffnet sind (obwohl es in vielen einfachen Fällen weiter funktioniert). Subtree_checking wird auch benutzt, um sicherzustellen, dass Dateien in Verzeichnissen auf die nur root Zugriff hat, nur zugreifbar sind, wenn das Dateisystem mit der `no_root_squash`-Option (siehe unten) exportiert wurde, auch wenn die Datei selbst weniger restriktive Zugriffsmodi hat. Als genereller Hinweis mag gelten, dass ein Home-Verzeichnis-Dateibaum, der normalerweise von seiner Wurzel aus exportiert wird und auf dem häufig Dateien umbenannt werden, ohne "subtree_checking" exportiert werden sollte. Ein Dateisystem, das größtenteils nur lesbar ("read only") ist und auf dem zumindest selten Dateien umbenannt werden (z.B. '''/usr''' oder '''/var''') und aus dem Unterverzeichnisse exportiert werden, sollte mit "subtree_checking" versehen werden. X* +++ `insecure_locks` `no_auth_nlm` Diese Option (die beiden sind Synonyme) weist den NFS-Server an, bei Dateisperranfragen ("locking", z.B. Nachfragen, die das NLM-Protokoll benutzen) keine Authentifizierung zu verlangen. Normalerweise würde der NFS-Server einen Sperrmechanismus verlangen, um einen Berechtigungsnachweis für Nutzer zu verwalten, die Lesezugriff auf die Datei haben. Mit dieser Option werden keine Zugriffsüberprüfungen gemacht.[[BR]] Alte NFS-Client-Implementationen haben keine Berechtigungsnachweise zusammen mit Sperrnachfragen verschickt, und es gibt viele NFS-Clients, die auf diesen alten Architekturen basieren. Diese Option sollte also benutzt werden, wenn auffällt, dass nur Dateien gesperrt werden können, die von allen Nutzern lesbar sind. Die voreingestellte Option, Authentifizierung für NLM-Nachfragen zu verlangen, kann explizit mit einem der Synonymen `auth_nlm` oder `secure_locks` angegeben werden. - +++ Optionen zum UID/GID-Mapping in der '''/etc/exports''' +++ `root_squash` Weist alle Anfragen der UID/GID 0 auf die UID/GID anonymous zu. Zu beachten ist, dass damit andere sensible bzw. mächtige UserIDs wie etwa "`bin`" oder "`staff`" nicht geändert werden. X +++ `no_root_squash` Legt man als Nutzer `root` per NFS Dateien oder Verzeichnisse an, werden diese standardmäßig dem Nutzer `nobody` zogeordnet ('root_squash'). Um dieses Sicherheitsmerkmal von 'root_squash' zu umgehen und die, vom User `root` geschriebenen Daten, auf dem Server nicht auf einen anderen User als ihn selbst zu mappen (UID/GID 0 bleiben erhalten), verwendet man den Parameter 'no_root_squash'. - +++ `all_squash` Ordnet alle UserIDs dem Nutzer `anonymous` zu. Nützlich für NFS-exportierte öffentliche FTP-Verzeichnisse oder News-Spool-Verzeichnisse. - +++ `anonuid` `anongid` Diese Option setzt die anonyme User- und Gruppen-ID explizit auf die angegebenen Werte. Diese Option ist primär für PC/NFS Clients gedacht, wo davon ausgegangen wird, dass alle Nachfragen von einem bestimmten Rechner immer von einer Person kommen. Beispiel: `/home/joe pc001(rw,all_squash,anonuid=150,anongid=100)` }}} *: default Einstellung seit nfs-utils 1.0.1 {{{#!vorlage Warnung * Zwischen Freigabe und der Parameterklammer darf kein Leerzeichen stehen: z.B. * `192.168.1.13(ro,async)` und __nicht__ * `192.168.1.13 (ro,async)` * `insecure` sollte nur verwendet werden, wenn es unbedingt notwendig ist, da dann auch die unsicheren Ports verwendet werden. Leider verwendet Mac OS X von Apple diese Ports für NFS-Verbindungen. Ein aktueller Apple-Computer kann sich nur dann mit dem NFS-Server verbinden, wenn die Option `insecure` gesetzt ist. * bei `nohide` sollte man beachten, dass es dadurch passieren kann, dass verschiedene Dateien, welche auf unterschiedlichen Partitionen bzw. Dateisystemen die gleiche Inode-Nummer haben, im aktivierten ("mounted") übergeordneten Verzeichnis die gleiche Inode-Nummer auf demselben (NFS-)Dateisystem haben; manche Treiber verkraften das nicht. Ggf. führt es beim Client zu einer Kernel Panic, wenn gleichzeitig lesend und schreibend auf den Server zugegriffen wird. Beispiel: NFS-Freigabe für Verzeichnis '''/media''' für eine VirtualBox (auf Servern sollte man das Verzeichnis '''/media''' nicht mounten, da sich dort ja auch Wechseldatenträger automatisch einhängen und von anderen auch darauf zugegriffen werden könnte): {{{ /media 192.168.56.0/24(rw,async,insecure,no_subtree_check,crossmnt) \}}} Die Option `crossmnt` sorgt dafür, dass der Client auch auf die eingehängten Dateisysteme unterhalb des Verzeichnisses '''/media''' zugreifen kann, z.B.: '''/media/Win7''', '''/media/SD-Karte''', '''/media/CD''' usw. }}} Damit sich der Rechner `notebook` als Client auch zu der Freigabe '''/PFAD/ZUR/FREIGABE3''' verbinden kann, muss er mit der IP-Adresse in der Datei '''/etc/hosts''' [3] des Servers stehen. Die Zeilen in dieser Datei sind wie folgt aufgebaut, dabei ist die Angabe des FQDN `COMPUTERNAME.DOMAIN.tld` optional: {{{ IP COMPUTERNAME COMPUTERNAME.DOMAIN.tld }}} z.B.: {{{ 192.168.1.12 notebook notebook.meinedomain.local 192.168.1.13 desktop desktop.meinedomain.local }}} Die FQDN (beispielsweise `notebook.meinedomain.local`) müssen nur dann angegeben werden, wenn man diese auch so in der Datei '''/etc/exports''' benutzt. Wenn man in der Datei '''/etc/exports''' auf die Verwendung symbolischer Rechnernamen verzichtet und direkt mit IP-Adressen arbeitet, muss man in der Datei '''/etc/hosts''' nichts ändern. Nun muss dem NFS-Server im Terminal [2] nur angewiesen werden, '''/etc/exports''' neu einzulesen. {{{#!vorlage Befehl sudo exportfs -ra }}} Alternativ kann der gesamte NFS-Server neu gestartet werden: {{{#!vorlage Befehl sudo service nfs-kernel-server restart }}} Die eventuell auftauchende Warnung ''"exportfs: No options for..."'' kann ignoriert werden. Die exportierten Freigaben können nun per `showmount` von einem Client abgefragt werden: {{{#!vorlage Befehl showmount -e NFS_SERVER }}} `NFS_SERVER` steht hierbei natürlich für den Namen oder Adresse des NFS-Servers [[Anker(ACL)]] == Zugriffskontrolle == Der NFS-Server beachtet die Zugriffsbeschränkungen, die durch die Dateien '''/etc/hosts.allow''' und '''/etc/hosts.deny''' beschrieben werden (siehe auch `man hosts_access`). Falls man diese Art der Zugriffskontrolle (zusätzlich zu der aus '''/etc/exports''') verwenden will, sind folgende Einträge vorzunehmen (für den Fall, dass diese Dateien noch nicht existieren, kann man sie einfach selber anlegen): In der '''/etc/hosts.deny''': {{{ portmap: ALL }}} Und in der '''/etc/hosts.allow''': {{{ # falls nur die IP 192.168.1.13 Zugriff erhalten soll: portmap: 192.168.1.13 # falls das gesamte LAN Zugriff erhalten soll: portmap: 192.168.1. # oder portmap: 192.168.1.0/24 }}} Auf dieselbe Art sollte man dann auch den Zugriff auf den `mountd` und den `statd` beschränken. Zu beachten ist, dass für diese Dienste nur IP-Adressen in den hosts_access-Dateien funktionieren, keine Domain-Namen. {{{#!vorlage Hinweis Die Einschränkung des `statd` bietet sich auch auf Client-Rechnern an, insbesondere auf Notebooks, die auch mal in unsicheren Netzen unterwegs sind. Hier muss der Zugriff nur dem/den Server(n) erlaubt werden. }}} = Auf Freigaben zugreifen = {{{#!vorlage Hinweis Weil NFS vom [:gio_mount:GVFS] nur eingeschränkt unterstützt wird, können die Dateimanager [:Nautilus:], [:Thunar:] und andere nicht direkt auf NFS-Freigaben zugreifen und Netzwerke auch nicht nach NFS-Freigaben durchsuchen. Zum Durchsuchen des Netzwerks eignet sich der Befehl `showmount`; als Alternative bietet sich auch [:Autofs#NFS-Freigaben-browsen:Autofs] an. }}} Damit der Client auf die Freigaben zugreifen kann, muss er sie einfach einbinden können. Hierzu ein Terminal öffnen [2] und {{{#!vorlage Befehl cd /media sudo mkdir MEINEFREIGABE sudo mount ipadresse:/PFAD/ZUR/FREIGABE /media/MEINEFREIGABE }}} eingeben. Im Falle einer Notebookfreigabe sieht das etwa so aus: {{{#!vorlage Befehl cd /media sudo mkdir server sudo mount 192.168.1.13:/home /media/server }}} Man könnte nun ein Shell-Script schreiben, das bei Aufruf eine Verbindung zum Server herstellt. (Achtung: Wenn das Verzeichnis schon erstellt wurde, braucht dieses natürlich nicht mehr erstellt zu werden.) Die zweite Möglichkeit ist, das Ganze mit Root-Rechten in die '''/etc/fstab'''-Datei[4] zu schreiben [3]. Beispiel für den Eintrag in die '''/etc/fstab''': {{{ 192.168.6.13:/home /media/server nfs rw 0 0 }}} {{{#!vorlage Tabelle Weitere Optionen in der '''/etc/fstab''' +++ Option Beschreibung +++ `rw` Lese- und Schreibrechte +++ `ro` Nur Leserechte +++ `hard` Bei Unterbrechungen ohne Timeout warten, bis der Server wieder normal erreichbar ist +++ `soft` Bei Unterbrechungen sofort einen Timeout machen (verhindert ein Einfrieren des Dateimanagers) +++ `timeo=` In Verbindung mit `soft` kann festgelegt werden, wann der Timeout erfolgen soll. +++ `bg` Bei einem Timeout wird im Hintergrund weiter versucht, das Dateisystem zu aktivieren ("mount"). Ist z.B. bei einem Laptop, das sich im Heimnetz automatisch mit einem NFS-Server verbinden soll, nützlich. +++ `intr` Erlaubt einem wartenden Programm, bei Bedarf dennoch zu unterbrechen oder abzubrechen +++ `nolock` Deaktiviert das Sperren von Dateien. Wird gelegentlich für die Verbindung zu alten NFS-Servern benötigt +++ `rsize=8192,wsize=8192` Mit diesen beiden Optionen kann man die Blockgröße der übertragenen Daten festlegen. In den meisten Fällen ist es nicht empfehlenswert, diese Optionen zu setzen. Server und Client handeln diese Werte selbst aus und erreichen so ein Maximum an Durchsatz. [[Vorlage(Warnung, "Falsche Werte können die Geschwindigkeit von NFS um bis zu '''50%''' reduzieren.")]] +++ `_netdev` Die `_netdev`-Option weist das System an, solange mit dem Versuch zu warten, einen "Share" zu mounten, bis das Netzwerk erreichbar ist. }}} Weitere Optionen stehen in der [:man:Manpage] zu nfs und [:fstab:]. {{{#!vorlage Hinweis Portmap öffnet seinen Port standardmäßig an allen Netzwerkschnittstellen, was auf einem Client-Rechner nicht unbedingt erwünscht ist (vor allem bei Laptops, die auch in anderen Netzen unterwegs sind). Man kann das ändern, indem man einfach folgenden Befehl ausführt und die Frage, ob "Portmap" nur an "localhost" gebunden werden soll, mit einem ''JA'' beantwortet. Damit ist der Port von anderen Rechnern nicht mehr erreichbar. {{{#!vorlage Befehl sudo dpkg-reconfigure portmap \}}} }}} = Problembehebung = Sollten beim Zugriff auf NFS-Freigaben Probleme auftreten (z.B. Fehlermeldungen der Art ''"Permission denied"'', kein Schreibzugriff, scheinbar leere Ordner oder Ähnliches), so hängt dies sehr häufig mit mangelnden bzw. fehlerhaft vergebenen [:Rechte: Rechten] im eingebundenen (entfernten) Dateisystem zusammen. Wird als Einhängepunkt versehentlich ein auf dem Client nicht existierendes Verzeichnis angegeben, etwa aufgrund eines Schreibfehlers in '''/etc/fstab''', so erhält man die [topic:kein-zugriffsrecht-auf-nfs-freigabe-uebersehe-:irreführende] Fehlermeldung, es bestünde ein Rechteproblem, etwa {{{#!code bash mount.nfs: mount(2): Permission denied mount.nfs: access denied by server while mounting 192.168.178.171:/home/user/schreibfehlre/ }}} Weitere Hinweise hierzu finden sich vor allem unter [:mount#Rechte:mount -> Rechte ] sowie [:mount#Externe-Laufwerke-einhaengen:Externe Laufwerke einhängen]. {{{#!vorlage Hinweis Bei der Freigabe von Dateien auf VFAT-Partitionen (FAT32) über NFS muss mit Problemen gerechnet werden. Als Ausweg empfiehlt sich [:Samba:]. }}} == Verzögerung beim Shutdown == Bedingt durch [:systemd:] können beim Shutdown erhebliche Verzögerungen auftreten, falls noch NFS- oder cifs-Freigaben gemountet sind. Im Artikel [:mount.cifs/#Shutdown-und-Reboot:] ist ein Workaround beschrieben, der leicht für NFS-Freigaben angepasst werden kann. = Links = ==Intern== * [:NFSv4:] - Der Wikiartikel zu NFSv4 * [:Serverdienste:] {Übersicht} – Übersichtsartikel * [:Heimnetzwerk:] {Übersicht} – Einführender Artikel; betrifft vor allem einfache Anwendungen * [:Autofs:] – Erlaubt auch die Auswahl ("browse") und das Einbinden von NFS-Freigaben ==Extern== * [http://www.selflinux.de/selflinux/html/nfs.html NFS] {de} – Ausführliche Erklärung (für fortgeschrittene Benutzer) von Selflinux.de * [archwiki:NFS#Server: NFS] {en} – Eintrag im Archlinux-Wiki # tag: Netzwerk, Server, Freigaben