|
|
| Zeile 117: |
Zeile 117: |
|
| |
|
| </noinclude> | | </noinclude> |
|
| |
|
| |
|
| |
|
| |
|
| |
| = TMP =
| |
| == Datenübertragung ==
| |
| ; Schematischer Ablauf der Datenübertragung
| |
| Im Folgenden ist der prinzipielle Ablauf einer NFS-Kommunikation des alten zustandslosen NFS bis einschließlich Version 3 beschrieben
| |
| * Szenario: Ein Nutzer des Client-Rechners möchte ein entferntes Verzeichnis ''(/directory)'' öffnen und eine darin befindliche Datei ''(test)'' anzeigen lassen
| |
|
| |
| Damit ein Datenaustausch zwischen NFS-Server und -Client stattfinden kann, muss der NFS-Server gestartet und beim [[Portmapper]] registriert sein
| |
|
| |
| # [[Client]] kontaktiert Portmapper auf Port 111 und fragt nach dem [[Port (Netzwerkadresse)|Port]] des [[Mounten|Mount]]-[[Daemon]]s (mountd)
| |
| # Portmapper gibt Portnummer für mountd heraus
| |
| * Typischerweise ist das 694
| |
| # Client kontaktiert mountd und fragt nach einem [[Filehandle]] für ''/directory'', des vom Clienten zu mountenden Verzeichnisses des Servers
| |
| # mountd gibt ein ''Filehandle 0'' als ''root''-Filehandle für das zu mountende Verzeichnis des Servers zurück
| |
| # Client kontaktiert Portmapper und fragt nach dem Port für NFS (nfsd)
| |
| * Typischerweise ist das 2049
| |
| # Portmapper gibt Portnummer für nfsd heraus
| |
| # Client führt ''LOOKUP''-[[Prozedur (Programmierung)|Prozedur]] aus mit den Parametern ''Filehandle 0'' und dem Dateinamen ''(test)''
| |
| # nfsd gibt ''Filehandle 1'' für Datei ''(test)'' heraus
| |
| # Client führt ''READ''-Prozedur aus mit dem Parameter ''Filehandle 1''
| |
| # nfsd gibt Inhalt der Datei ''(test)'' zurück (Daten)
| |
|
| |
| == Design ==
| |
| ; Design der frühen Versionen des Systems
| |
| Ein Programm greift auf das Dateisystem über [[Systemaufruf]]e zu
| |
| * Unter [[Unix]] sind die wichtigsten Systemaufrufe
| |
| * ''open'', ''close'' – Öffnen und Schließen einer Datei
| |
| * ''read'', ''write'' – Lesen und Schreiben
| |
| * ''create'', ''unlink'' – Erzeugen und Löschen
| |
| * ''mkdir'', ''rmdir'' – Erzeugen und Löschen eines Verzeichnisses
| |
| * ''readdir'' – Lesen von Verzeichniseinträgen
| |
|
| |
| Ein Netzwerkdateisystem muss diese Aufrufe in Netzwerkpakete verpacken und an einen [[Server]] senden
| |
| * Dieser antwortet dann mit der entsprechenden Information oder einem Fehler
| |
|
| |
| Die Entwickler von Sun Microsystems entschieden sich zunächst für ein [[Remote Procedure Call|Remote-Procedure-Call]]-Modell. [[External Data Representation|XDR]] setzt die Parameter des ''RPCs'' in ein maschinenunabhängiges Format um, die Zugriffe werden dann über den RPC Mechanismus wie ein normaler Unterprogrammaufruf behandelt
| |
|
| |
| Die Systemaufrufe werden aber nicht direkt in RPC-Aufrufe umgesetzt, da dann eine über ''open'' geöffnete Datei auch auf dem Server geöffnet werden müsste
| |
| * Bei vielen Clients wären die Server dann schnell überlastet, da die Maschinen Mitte der 1980er-Jahre noch relativ wenig Speicher hatten
| |
| * Die Aufgaben des Servers wurden daher so einfach wie möglich gehalten, der Server merkt sich keine Dateiinformationen zwischen zwei RPC-Aufrufen
| |
| * Er ist also zustandslos
| |
|
| |
| Statt ''open'' wird ein ''lookup''-Aufruf implementiert
| |
| * Dieser liefert ein Datei-„Handle“, das die [[Inode]]nummer und die Gerätenummer des Massenspeichers auf dem Server enthält. Über dieses Handle kann eine Datei auf dem Server eindeutig identifiziert werden
| |
| * Unter Unix steht über diese beiden Nummern die Dateiinformation effizient ohne aufwändige Suche eindeutig zur Verfügung
| |
|
| |
| Die weiteren Aufrufe wie ''read'' oder ''write'' müssen stets ein Offset übergeben, so dass der Server auch hier ohne Kenntnis früherer Operation die gewünschte Information eindeutig liefern kann
| |
|
| |
| Weitere Eigenschaften des Protokolls sind
| |
| * nur kurze [[Cache]]zeiten (wenige Sekunden) für Verzeichnisinformationen und Dateiattribute
| |
| * kein Datencache
| |
| * Verwendung des verbindungslosen User Datagram Protocols ([[User Datagram Protocol|UDP]]) optional [[Transmission Control Protocol|TCP]] (NFSv4 nur TCP)
| |
| * Lock- und Mount-Operationen über zusätzliche Hilfsprotokolle
| |
| * Verwendung von Unix-Dateiattributen (zum Beispiel Benutzer-''uid'')
| |
|
| |
| Wegen des einfachen Designs läuft NFS in normalen Umgebungen gut
| |
| * lokales Netzwerk mit kurzen [[Antwortzeit]]en
| |
| * Ausführen von Programmen über das lokale Netzwerk
| |
| * Normale Benutzeraktivitäten (Editieren, Programme übersetzen)
| |
| * Server mit relativ wenig Arbeitsspeicher
| |
|
| |
| Weniger gut ist das Verhalten bei
| |
| * gemeinsamer Nutzung von Dateien
| |
| * Verwendung über das Internet (lange Antwortzeiten, geringe Sicherheit)
| |
| * Verwendung von Firewalls (UDP, kein fester Port wegen ''Portmapper'') (Unter NFSv4 kein Problem mehr; jegliche Kommunikation läuft über Port 2049/TCP)
| |
|
| |
| Das Protokoll wurde Ende der 1980er-Jahre entwickelt
| |
| * Auch teure [[Workstation]]s hatten zu dieser Zeit nur wenige [[Mebibyte]]s Arbeitsspeicher, typisch etwa 4 bis 8 [[Mebibyte|MiB]]
| |
| * Ein NFS-Server kann auf solchen Maschinen aufgrund des Designs trotzdem effizient betrieben werden
| |
|
| |
| Wegen des zustandslosen Servers kann dieser ohne Datenverlust heruntergefahren und neu gestartet werden
| |
| * Programme stürzen nicht ab und Benutzer müssen dann einfach warten, bis der Server wieder verfügbar ist
| |
|
| |
| == Festplattenlose Arbeitsrechner ==
| |
| [[Arbeitsrechner]] (Workstations) können über NFS ganz ohne Festplatte betrieben werden
| |
| Das Betriebssystem und die Betriebsparameter können über Protokolle wie [[Bootstrap Protocol|BOOTP]] und [[Trivial File Transfer Protocol|TFTP]] geladen werden
| |
| * Ein spezieller Kernel (z. B
| |
| * Linux) kann dann über NFS bereits auf das Root-Laufwerk unter Unix zugreifen
| |
| * Spezielle plattenlose Arbeitsrechner ''([[Diskless-Workstation|diskless workstations]])'' wurden von der Firma Sun in den 1990er-Jahren angeboten
| |
|
| |
| Vorteile sind ein verringerter Wartungsaufwand, gemeinsame Nutzung von Speicherplatz sowie einfachere und preiswerte Client-Workstations ([[Thin Client]]s)
| |
| * Bei vielen Clients wird der Server jedoch stark belastet, außerdem sind die Zugriffe über Netzwerk in den meisten Fällen langsamer
| |
|
| |
| == PC-NFS ==
| |
| Sun und andere Firmen boten in den 1990er Jahren auch NFS-Clientsoftware für PCs unter [[Microsoft Windows|Windows]] an, das PC-NFS
| |
| * Der Server musste weiterhin eine Unix-Workstation sein
| |
| * Bis [[Windows for Workgroups]] war der Netzwerkzugriff unter Windows nicht Teil des Betriebssystems
| |
| * In Unix-Umgebungen wurde der Einsatz von PCs dadurch wesentlich erleichtert
| |
|
| |
| PC-NFS musste mit den unterschiedlichen Konzepten des DOS/Windows-Systems kämpfen
| |
| * Die damaligen Windows-Versionen erlaubten nur Dateinamen mit bis zu acht Zeichen sowie eine drei Zeichen lange Erweiterung, die durch einen Punkt abgetrennt wurde (z. B. <code>AUTOEXEC.BAT</code>, die sogenannte [[8.3]]-Notation), während Unix 255 Zeichen lange Pfadnamen erlaubte
| |
| * Die Dateinamen unterschieden im Gegensatz zu DOS zwischen Groß- und Kleinschreibung
| |
| * PC-NFS musste also zwischen den Dateinamenkonzepten übersetzen
| |
|
| |
| Ein Unix-Dateiname ''file.txt'' erschien als <span style="font-family:monospace;">FILE.TXT</span> unter Windows/DOS, während ein Dateiname ''Dokumentation.txt'' etwa in <span style="font-family:monospace;">DOKUME~1.TXT</span> umgesetzt wurde
| |
|
| |
| == NFS Version 4 ==
| |
| Die NFS Version 4 stellt eine Neuimplementierung dar, die neuere Erfordernisse berücksichtigt
| |
| * Sie ist in <nowiki>RFC 7530</nowiki> standardisiert
| |
|
| |
| Die Unix-Lastigkeit der frühen Versionen wird so weit wie möglich verringert
| |
| * Die UNIX-Benutzer- und Gruppennummern werden durch eindeutigere Zeichenketten nach dem Muster nutzer@domain ersetzt. ''nutzer'' ist hierbei der Nutzername auf dem Server, ''domain'' ist die Domain des Servers, also der Teil des Hostnamens, der nicht den Server selbst identifiziert (''srv.cs.example.net'' → ''cs.example.net'')
| |
| * Durch die Kennung ''user@cs.example.net'' kann nun auf allen Rechnern der Domain ''cs.example.net'' der Nutzer eindeutig identifiziert werden, auch wenn der Nutzer ''user'' auf dem Server die Unix-User-ID 1050 hat und auf dem Client z. B. 1100
| |
| * Dies führte bei früheren NFS-Versionen zu Problemen, wenn keine konsistente Nutzernummerierung eingehalten wurde
| |
| * Für die Umsetzung der neuen NFS-Nutzernamen in (Unix-)Nutzer-IDs ist unter Linux zum Beispiel der Dienst ''rpc.idmapd'' ('''''ID''' '''map'''per '''d'''aemon''), unter [[FreeBSD]] der [[Daemon]] ''nfsuserd'' ('''''NFS''' '''user''' '''d'''aemon'') zuständig (sowohl für Server- als auch für Clientseite)
| |
| * Die Nutzernamen werden nur richtig zugeordnet, wenn Server und Client die gleiche Domain haben, ansonsten wird als Eigentümer ''nobody.nogroup'' angegeben
| |
|
| |
| Da manche Dateisysteme keine effiziente Implementierung von eindeutigen [[Datei-Handle]]s ermöglichen, werden ''flüchtige'' [[Handle]]s eingeführt, die nur eine bestimmte Zeit zur Verfügung stehen
| |
| * Unter Unix kann man Handles sehr einfach aus der Geräte- und [[Inode]]-Nummer konstruieren
| |
| * Auch Dateisysteme, die nicht zwischen Groß- und Kleinschreibung unterscheiden, sowie benutzerdefinierte Dateiattribute werden jetzt unterstützt
| |
|
| |
| Das [[Mounten|Mount]]- und [[Lock]]protokoll sind jetzt Bestandteil des Protokolls selbst, Hilfsprotokolle werden nicht mehr benötigt
| |
| * Das Protokoll selbst läuft auf dem festen [[Transmission Control Protocol|TCP]]-Port ''2049'', [[User Datagram Protocol|UDP]] wird nicht mehr unterstützt
| |
| * Zwar liefen auch schon frühere Versionen auf diesem Port, die Hilfsprotokolle wurden vom RPC-Portmapper aber dynamisch zugeteilt
| |
| * Die Verwendung von [[Firewall]]s bei NFS-Verbindungen wird durch diese Maßnahmen stark vereinfacht
| |
|
| |
| Mehrere Anfragen können gebündelt werden ''(combined request)'', sie werden dann vom Server ausgeführt und nur eine Antwort muss zurückgesendet werden
| |
| * Das Protokoll kann damit effizient auch im Weitverkehrsbereich ([[Wide Area Network|WAN]]) eingesetzt werden, zum Beispiel zwischen verschiedenen Standorten einer Organisation
| |
|
| |
| Verschlüsselung und [[Authentifizierung]] sind jetzt Teil der [[Spezifikation]]
| |
| * Zwar war früher schon über Secure-RPC eine Verschlüsselung möglich
| |
| * Das wurde nur selten genutzt, unter anderem, weil Secure-RPC nicht überall zur Verfügung stand
| |
|
| |
| Der ''lookup''-Aufruf wird durch ''open'' ersetzt, die Speicherung von Dateiinformationen wird dadurch möglich
| |
| * Beispielsweise könnte die Schreib-/Leseposition auf dem Server verwaltet werden
| |
| * Auch die gemeinsame Nutzung von Dateien wird besser unterstützt
| |
| * Falls viele Clients eine Datei nur lesen, kann diese an alle Clients verliehen ''(leases)'' werden
| |
| * Wenn ein Client eine Datei schreiben möchte, kann diese exklusiv verliehen werden
| |
|
| |
| In Version 4.1 ist unter anderem paralleler Zugriff auf über mehrere Server verteilten Speicher hinzugefügt worden
| |
| * Ab Version 4.2 im November 2016 werden serverseitige Kopien und Sparsefiles unterstützt
| |
|
| |
| == Konfiguration in Unix-Systemen ==
| |
| Die NFS-Freigaben werden unter Unix serverseitig meist in der Datei /etc/exports festgelegt, die nach dem folgenden Schema aufgebaut ist
| |
| * Dabei sind die Unterschiede zwischen Linux- und FreeBSD-Systemen zu beachten
| |
|
| |
| # Server-Adresse: 10.0.0.1
| |
| # NFSv2, NFSv3
| |
| # Exportiert /path/to/directory an alle IPs von 10.0.0.0 bis 10.0.255.255,
| |
| # und zwar zum Lesen/Schreiben (rw), asynchronem Zugriff (Daten werden
| |
| # nicht sofort geschrieben) und auch von Ports über 1024 aus (insecure)
| |
| #
| |
| # Erreichbar als: 10.0.0.1:/path/to/directory
| |
| #
| |
| ### Linux-Systeme
| |
| /path/to/directory 10.0.0.0/16(rw,async,insecure)
| |
|
| |
| ### FreeBSD
| |
| /path/to/directory -network 10.0.0.0/16
| |
|
| |
| # NFSv4
| |
| # Benötigt zur optimalen Funktion eine Freigabe mit der Option ''fsid=0''
| |
| # Diese wird als root-Freigabe genutzt und ist als die Freigabe / zu
| |
| # erreichen
| |
| * Die anderen Freigaben liegen unterhalb davon
| |
| * Ansonsten
| |
| # ist optional eine Authentifizierung/Verschlüsselung mit [[Kerberos (Informatik)|Kerberos]]
| |
| # möglich
| |
| #
| |
| ### Linux-Systeme
| |
| # Erreichbar als 10.0.0.1:/
| |
| # Wird diese Freigabe eingehängt, so sind alle darunterliegenden
| |
| # Freigaben logischerweise zugänglich
| |
| /path/to/nfsv4/root 10.0.0.0/16(rw,async,insecure,'''fsid=0''')
| |
| # Erreichbar als 10.0.0.1:/export1
| |
| /path/to/nfsv4/root/export1 10.0.0.0/16(rw,async,insecure)
| |
|
| |
| ### FreeBSD
| |
| # Root-Punkt spezifizieren (unter Linux der mit fsid=0 markierte Punkt)
| |
| V4: /path/to/nfsv4/root -network 10.0.0.0/16
| |
| # Freigaben angeben
| |
| /path/to/nfsv4/root/export1 -network 10.0.0.0/16
| |
|
| |
| Der Client kann eine Freigabe manuell mounten oder ggf
| |
| * mit einem Eintrag in der Datei [[fstab]] automatisieren
| |
|
| |
| Vielen aktuellen [[Linux-Distribution]]en liegen grafische Hilfswerkzeuge bei, um die Einbindung von NFS-Freigaben ins System zu vereinfachen, zum Beispiel das NFS-[[YaST]]-Plugin unter [[openSUSE]]
| |
|
| |
| == Sicherheit ==
| |
|
| |
| === NFS Version 3 und früher ===
| |
| NFS wurde geschaffen, um in Unix-Netzen [[Dateisystem]]e über Rechnergrenzen hinweg zugänglich zu machen
| |
| * Zur Zeit der Entwicklung von NFS waren solche Netze fast ausschließlich zentral verwaltet und die Rechner wurden zentral administriert, entsprechend wurde das Sicherheitskonzept gestaltet
| |
|
| |
| Die Entwickler von NFS bei Sun Microsystems hatten ursprünglich vorgesehen, die Sicherheit als Aufgabe der RPC-Schicht zu implementieren
| |
| * Dazu wird RPC durch Secure-RPC ersetzt
| |
| * Die NFS-Protokolle selbst bleiben davon unberührt
| |
| * Secure-RPC hat allerdings keine weite Verbreitung gefunden, die Verwendung ist auch nicht bei allen Implementierungen möglich
| |
|
| |
| Ein NFS-Server ohne Secure-RPC exportiert Dateisysteme an bestimmte andere Rechner (von [[Root-Konto|root]] durch [[IP-Adresse]]n festgelegt), d. h
| |
| * der root-User eines Clientrechners kann auf alle Dateien zugreifen, die der Server an den Client exportiert, unabhängig von deren Zugriffsrechten
| |
| * Die Zugriffsrechte (der Benutzer) werden von NFS an den Client mitübertragen und vom Betriebssystem des jeweiligen Rechners ausgewertet und gegenüber den Benutzern durchgesetzt
| |
| * Die Konsistenz der Benutzerdatenbank auf den beteiligten Rechnern wird dabei z. B
| |
| * durch [[Network Information Service|NIS]] erreicht
| |
|
| |
| Heute sind Rechnernetze häufig offen und nur bedingt zentral administriert, d. h
| |
| * ein Angreifer kann relativ einfach entweder einen Rechner übernehmen, dem der NFS-Server vertraut, indem er ihn z. B
| |
| * mit einem [[Live-System]] neu bootet oder einen zusätzlichen Laptop ins Netz hängt und die IP eines gerade nicht laufenden NFS-Clients annimmt
| |
| * In beiden Fällen kann der Angreifer, da er auf seinem System Rootrechte hat, auf alle an den Client exportierten Dateien zugreifen, unabhängig von deren Zugriffsrechten
| |
| * Somit ist NFS v3 ohne separat installiertes [[Kerberos (Protokoll)|Kerberos]] immer nur so sicher wie das Netz und die beteiligten Rechner
| |
|
| |
| Mit der Server-Option ''root_squash'' (unter FreeBSD mit der in der entsprechenden Zeile anzugebenden Option <span style="font-family:monospace;">-maproot=<USER></span>) kann man das oben genannte Szenario unterbinden
| |
| * Damit werden Zugriffe durch Benutzer mit der UID 0 (meist ''root'') als Zugriffe des anonymen Benutzers (UID=65534) gewertet, der dann u. U
| |
| * keinerlei Zugriffsrechte auf die freigegebenen Dateien hat
| |
| * Ein Angreifer muss nun beim Verbinden so lange unterschiedliche UIDs ausprobieren, bis er die UID des Benutzers oder der Gruppe erwischt, die berechtigt ist
| |
| * Da es nur <math>2^{16}</math> (65536) UIDs gibt, bietet auch dieses Vorgehen keine echte Sicherheit
| |
|
| |
| === NFS Version 4 ===
| |
| NFSv4 löst dieses Problem, indem z. B. [[Kerberos (Informatik)|Kerberos]] nun Bestandteil des Protokolls ist und eine Authentifizierung der Benutzer ermöglicht
| |
| * Zudem lässt sich mit einer ebenfalls optionalen Verschlüsselung auch die [[Vertraulichkeit]] sicherstellen
| |
|
| |
| ==== Verfügbare Sicherheitsmodi ====
| |
| Beim Verbinden kann einer der folgenden Mechanismen gewählt werden, um das Sicherheitsniveau (welches auch die Übertragungsgeschwindigkeit beeinflusst) festzulegen
| |
| {| class="wikitable"
| |
| |-
| |
| ! Bezeichnung
| |
| ! Bedeutung
| |
| ! Mount-Option
| |
| |-
| |
| | sys
| |
| | Benutzeridentifikation erfolgt nach dem Schema von NFS3
| |
| * Dies bietet sehr wenig Sicherheit
| |
| | sec=sys
| |
| |-
| |
| | krb5
| |
| | Server und Client authentifizieren sich gegenseitig unter Benutzung der [[GSSAPI|GSS]]-Schnittstelle mittels Kerberos
| |
| * Dies unterbindet das obige Angriffsszenario
| |
| | sec=krb5
| |
| |-
| |
| | krb5i
| |
| | Zusätzlich wird die Integrität der übertragenen Daten sichergestellt
| |
| * Dies verhindert eine Veränderung der Daten durch einen [[Man-in-the-Middle-Angriff|Man In The Middle]]
| |
| | sec=krb5i
| |
| |-
| |
| | krb5p
| |
| | Die Vertraulichkeit der übertragenen Daten wird zusätzlich zur Integrität gewährleistet
| |
| * Dies verhindert ein Mitlesen durch einen Angreifer im Netzwerk
| |
| | sec=krb5p
| |
| |}
| |
|
| |
| Eine Freigabe kann mehrere Mechanismen anbieten, aus denen der Client einen durch die Mount-Option auswählen kann
| |
|
| |
| ==== Alternative zu Kerberos ====
| |
| Allerdings wird des Öfteren bemängelt, dass mit Kerberos eine enorm komplexe und in einigen Umgebungen unmögliche Voraussetzung besteht
| |
| * Daher wird anstelle der eingebauten Sicherheitsfunktionen von NFS oft eine zusätzliche Sicherheits-Schicht wie [[Transport Layer Security|TLS]] genutzt
| |
|
| |
| == Normen und Standards ==
| |
| Die Version 1.0 hat [[Sun Microsystems]] im Jahr 1984 erstellt
| |
| * Ab der Version 2.0 erfolgte die weitere Standardisierung als [[Request for Comments]]
| |
| * Erst mit der Version 4.0 erfolgte der Wechsel vom Status Informational in Offizieller Standard
| |
| * Die drei Versionen 4.0, 4.1 und 4.2 sind alle zugleich aktuelle Standards, deshalb gibt es seit 2017 auch Ergänzungen ohne Versionsnummer
| |
|
| |
| a) Ursprünglicher Pfad von Version 2 zu Version 4.0
| |
| * {{RFC-Internet |RFC=1094 |Titel=NFS Version 2 Protocol Specification |Datum=1989 |Updated=3010}}
| |
| * {{RFC-Internet |RFC=1813 |Titel=NFS Version 3 Protocol Specification |Datum=1995 |Updated=3010}}
| |
| * {{RFC-Internet |RFC=3010 |Titel=NFS Version 4 Protocol |Datum=2000 |Updated=3530}}
| |
| * {{RFC-Internet |RFC=3530 |Titel=Network File System (NFS) version 4 Protocol |Datum=2003 |Updated=7530}}
| |
| * {{RFC-Internet |RFC=7530 |Titel=NFS Version 4 Protocol Specification |Datum=2015}}
| |
| * {{RFC-Internet |RFC=7931 |Titel=NFSv4.0 Migration: Specification Update |Datum=2016}}
| |
|
| |
| b) Neuere Versionen 4.x
| |
| * {{RFC-Internet |RFC=5661 |Titel=Network File System (NFS) Version 4 Minor Version 1 Protocol |Datum=2010 |Kommentar=NFS 4.1}}
| |
| * {{RFC-Internet |RFC=7862 |Titel=Network File System (NFS) Version 4 Minor Version 2 Protocol |Datum=2016 |Kommentar=NFS 4.2}}
| |
|
| |
| c) Ergänzungen für 4.x
| |
| * {{RFC-Internet |RFC=8178 |Titel=Rules for NFSv4 Extensions and Minor Versions |Datum=2017}}
| |
| * {{RFC-Internet |RFC=8434 |Titel=Requirements for Parallel NFS (pNFS) Layout Types |Datum=2018}}
| |
|
| |
| == Weblinks ==
| |
| # https://de.wikipedia.org/wiki/Network_File_System
| |
|
| |
| [[Kategorie:Freies Dateisystem]]
| |
| [[Kategorie:Internet-Dateiübertragungsprotokoll]]
| |
| [[Kategorie:Verteiltes Dateisystem]]
| |