Dieser Artikel ist größtenteils für alle Ubuntu-Versionen gültig.
Es gibt zuweilen gute Gründe, von Linux aus auf einen Datenträger mit einem Windows-Dateisystem zuzugreifen. Beispielsweise möchte man in einem Dual-Boot-System eine Partition eines eingebauten Datenträgers von Windows und von Linux aus wechselweise nutzen, oder man möchte einen externen Datenträger (Festplatte, SD-Karte oder USB-Stick) abwechselnd in Windows und Linux benutzen. Externe Geräte wie Musikplayer oder Fernseher, Kameras oder Navigationsgeräte können oftmals nur mit Datenträgern umgehen, die mit einem Windows-Dateisystem formatiert sind usw.
Ubuntu kann die Windows-Dateisysteme FAT12, FAT16, FAT32, exFAT und NTFS automatisch erkennen und auf diese lesend und schreibend zugreifen. Windows-Dateisysteme lassen sich genau wie originäre Linux-Dateisysteme automatisch beim Rechnerstart über /etc/fstab[2] oder im Dateimanager einfach mit einem Mausklick einbinden, und USB-Sticks oder externe Festplatten werden nach dem Anschließen automatisch eingebunden und auf dem Desktop angezeigt, dies funktioniert auch mit Windows-Dateisystemen.
Allerdings gibt es wesentliche technische Unterschiede zwischen Windows- und Linux-Dateisystemen und dadurch bedingt einige in diesem Artikel besprochene Besonderheiten und Einschränkungen, die es allgemein zu beachten gilt. Linux kennt für die jeweiligen Dateisystemtypen mehrere Möglichkeiten mit unterschiedlichen Eigenschaften, welche in diesem Artikel nur angerissen und in speziellen Artikeln (siehe Tabelle 1) ausführlich dargestellt werden. Zu den technischen Eigenschaften der einzelnen Dateisysteme lese den Artikel Dateisystem.
| Tabelle 1: Windows-Dateisysteme unter Linux | |||
| Typ | Kernel | FUSE | Hinweise |
| FAT12 | msdos vfat | Dateien müssen systembedingt bei FAT12 um mindestens 48 kiB kleiner als 16 MiB, bei FAT16 um mindestens 708 kiB kleiner als 2 GiB und bei FAT32 kleiner als 4 GiB sein. Siehe Artikel Dateisystem und hier. | |
| FAT16 | |||
| FAT32 | |||
| exFAT | exfat | Siehe Artikel exFAT. | |
| exfat-fuse | |||
| NTFS | ntfs | Seit langem enthält der Linux Kernel ein Modul ntfs, welches NTFS lesen und eingeschränkt schreiben kann; bei Ubuntu ist Schreiben jedoch ganz abgeschaltet. Wegen verfügbarer besserer Alternativen wird dieses Modul höchst selten willentlich eingesetzt, allerdings kann es nach dem Scheitern von ntfs-3g automatisch aktiviert werden. | |
| ntfs3 | Der Linux Kernel enthält seit Version 5.15 ein Modul ntfs3, das Lese- und Schreibvorgänge auf NTFS voll unterstützt. Siehe Artikel NTFS3. Hinweis:Eine Verwendung des neuen Moduls wird erst ab Kernel Version 6.4 empfohlen, da erst mit dieser Version wichtige Fehlerbereinigung und funktionale Erweiterungen erfolgten. | ||
| ntfs-3g ntfs | Das FUSE-Programm[5] ntfs-3g (NTFS-Treiber der 3.Generation) ist ein Treiber für das NTFS-Dateisystem bei Linux und anderen verwandte Betriebssystemen. Inzwischen bietet es optional die volle Unterstützung der UNIX-Besitz- und Zugriffsrechte[6] sowie der POSIX-ACL, die Interoperabilität mit Windows durch User-Mapping und die Vererbung von Besitzer- und Zugriffsrechten. Auch der transparente Schreib- und Lesezugriff in komprimierten Ordnern wird voll unterstützt. Siehe Artikel NTFS-3G. Alle Funktionen des früher eigenständigen Pakets ntfsprogs sind inzwischen bei Ubuntu im Paket ntfs-3g integriert. | ||
| SMB | cifs | Dieser Artikel behandelt nicht den praktischen Zugriff auf Freigaben anderer Windows- oder Linux-Rechner über ein Netzwerk und auch nicht die Einrichtung solcher Freigaben. Siehe dazu: * Samba * Heimnetzwerk * Samba Server GNOME (Abschnitt „Persoenliche-Freigaben-mit-net-usershare“) * Technische Besonderheiten bei der Freigabe von Windows-Dateisystemen | |
Die Einbindung eines Windows-Dateisystems unter Linux unterläuft grundsätzlich die Sicherheitsmechanismen und Dateiberechtigungen im Dateisystem unter Windows.
Das gilt in beiden Richtungen: Es können sowohl unter Linux Dateien von unter Windows Unberechtigten gelesen, aber auch von Linux aus jedem Benutzer unter Windows Dateien untergeschoben werden.
Ohne besondere Maßnahmen werden bei der Erstellung von Dateien unter Linux die Windows-Dateirechte immer auf „Jeder hat Vollzugriff“ gesetzt.
Es kann ein Sicherheitsrisiko bedeuten, sensible Daten oder Systemdateien auf Partitionen unterzubringen, auf die Windows und Linux abwechselnd Zugriff haben.
Dies gilt auch für NTFS, kann aber bei der Benutzung von ntfs-3g durch ein User-Mapping unterbunden werden.
Die Dateisysteme kontrollieren den Zugriff auf die in ihnen enthaltenen Dateien in konzeptionell höchst unterschiedlicher Art und Weise:
Linux-Dateisysteme wie beispielsweise ext2/3/4 verwenden die auf Benutzer und Benutzergruppen bezogenen UNIX-Dateirechte und ggf. zusätzlich POSIX ACLs.
Die Dateisysteme FAT12/16/32 und exFAT kennen hingegen überhaupt keine Besitzer für Dateien und daher auch keine für Benutzer individuellen Dateirechte.
NTFS verwendet die für Windows konzipierten, völlig anders strukturierten SIDs ggf. mit eigenen, nicht zu Linux kompatiblen ACLs.
Alle Windows-Dateisysteme kennen aber die unter Linux so nicht verwendeten Attribute READONLY, HIDDEN, SYSTEM und ARCHIV. Diese vom jeweiligen Benutzer unabhängigen Attribute sind unter Linux nicht oder nur sehr eingeschränkt zugreifbar.
Die Rechteverwaltung von Linux auf Windows-Dateisystemen funktioniert daher nicht bzw. wird durch feste Regeln ersetzt. Für diese Ersetzung gibt es die anschließend besprochenen Methoden. Die effektiv wirksamen Dateiberechtigungen hängen ab von den konkreten Verhältnissen beim Einhängen.
Diese Methode wird bei allen Dateisystem-Treibern für FAT und exFAT als einzig mögliche angewendet. Sie ist ebenfalls bei NTFS unter Verwendung von ntfs-3g die Standardmethode, die aber durch echte Dateirechte ersetzt werden kann.
Beim Einbinden werden für alle Ordner und Dateien im Windows-Dateisystem jeweils ein gemeinsamer Besitzer, eine gemeinsamer Gruppe und einheitliche Dateirechte festgelegt. Dabei werden die tatsächlich im Dateisystem gespeicherten Metadaten nicht verändert, sondern dies ist nur eine temporäre Sicht von Linux darauf. Die bei der Einbindung festgelegten Metadaten sind für die Dauer der Einbindung unveränderlich. Dabei gelten folgende Standard-Einstellungen:
Temporärer Besitzer des Dateien wird, sofern nicht explizit etwas anderes festgelegt wird. der Besitzer des Prozesses, welcher die Einbindung durchführt.
Als Gruppe der Datei wird, sofern nicht explizit etwas anderes festgelegt wird, die primäre Gruppe des Besitzers festgelegt.
Die Dateirechte berechnen sich aus dem Wert 777 (Vollzugriff) und dem beim Einbinden gültigen Wert für UMASK
Man kann diese Metadaten nur beim Einbinden mit den Mount-Optionen uid und gid sowie umask, fmask und dmask festlegen, wie im Artikel mount (Abschnitt „Windows-Dateisysteme“) genauer beschrieben.
Nach dem Einhängen lassen sich die simulierten Benutzer und Dateirechte im Dateimanager (z.B. Nautilus) oder mit den Befehlen chown, chgrp und chmod nicht mehr verändern, sondern sie gelten für die jeweilige Sitzung bis zum Aushängen des Dateisystems; beim erneuten Einhängen können sie unabhängig davon wieder neu und ganz anders festgelegt werden.
Diese Methode verwendet nur der Dateisystem-Treiber ntfs-3g optional alternativ zu den temporär simulierten Dateirechten.
Seit der Version 2009.11.14 (in Ubuntu seit 10.04 Lucid Lynx) bietet der von Ubuntu für NTFS verfügbare Dateisystem-Treiber NTFS-3G optional auch die Möglichkeit, Linux- bzw. UNIX-Dateirechte und -ACL auf die in NTFS verwendeten SID mit Windows-ACL abzubilden und ermöglicht so bei NTFS eine echte Verwaltung von Linux-Dateirechten. Mit User-Mapping lässt sich sogar erreichen, dass in Dual-Boot-Systemen Windows und Linux (mit gewissen Einschränkungen) gegenseitig die Dateirechte anerkennen.
Diese Methode verwendet nur der Dateisystem-Treiber ntfs3.
Der Treiber liest und schreibt für seine internen Zwecke spezielle erweiterte Attribute (Namen: $LXUID, $LXGID, $LXMOD) der einzelnen Dateien:
Bei vorhandenen Dateien ohne solche Attribute werden momentaner Besitzer, momentane Gruppe und Zugriffsrechte aus dem Ergebnis der Einbindung ererbt wie bei den temporär simulierten Dateirechten beschrieben.
Bei vorhandenen Dateien mit solchen erweiterten Attributen werden dagegen die Metadaten aus diesen übernommen und beachtet.
Änderungen dieser Metadaten unter Linux werden in den erweiterten Attributen nachvollzogen, ggf. werden benötigte Attribute angelegt.
Beim Anlegen einer neuen Datei von Linux aus werden die momentanen Verhältnisse in solche erweiterten Attributen eingetragen.
Unter Windows haben diese erweiterten Attribute keinerlei Bedeutung, es sei denn, man überträgt die Informationen in die Verwaltungsstrukturen von Windows. Es ist keine Software bekannt, mit der dies einfach und übersichtlich bedienbar wäre.
In der Praxis kann man damit unter Linux bzgl. der Dateirechte ein Dateisystem des Typs NTFS genauso bedienen wie ein bei einem unter Linux herkömmlichen Dateisystem.
Die Dateisysteme erlauben die Protokollierung von bestimmten Zeitpunkten während der Existenz einer Datei wie beispielsweise Erzeugung, letzte Änderung ihres Inhalts, letzte Änderung ihrer Verwaltungsdaten, letztes Lesen; allerdings verfügen die unterschiedlichen Dateisysteme über höchst unterschiedliche Möglichkeiten dafür und sind sich auch nicht einig, welche Ereignisse in welchem Zeitstempel (die je nach Autor Namen wie u.a. ctime, mtime, atime, crtime, btime tragen) zu erfassen sind. Dazu kommen noch je nach Betriebssystem unterschiedliche Auffassungen zum Gebrauch dieser Zeitstempel.
Beim Kopieren von Dateien zwischen Dateisystemen unterschiedlicher Typen oder Anzeige der Dateieigenschaften in verschiedenen Betriebssystemen können daher merkwürdige Effekte auftreten. Relativ häufig findet man Abweichungen von einer Stunde oder zwei Stunden, weil Windows mit Ortszeit (in der EU: MEZ bzw. MESZ) arbeitet und speichert, Linux aber intern immer mit der Weltzeit (UTC) arbeitet und speichert und nur zur Anzeige die Zeiten wandelt.
Grundsätzlich (und nicht nur beim Umgang mit Windows-Dateisystemen) sollte man die Zugriffszeit (atime) möglichst selten speichern, da deren häufige Speicherung die Lebensdauer von Flash-Speicher wie SSDs oder USB-Sticks reduziert ohne einen nutzbaren Vorteil zu bieten. Die meistens per Standard verwendete Mount-Option relatime verhindert unnötig häufige Speicherung der Zugriffszeit und sollte daher nur in besonderen Fällen verändert werden.
Bei Backup-Programmen (z.B. rsync oder FreeFileSync) können die Unterschiede bei den Zeitstempeln zwischen Dateisystemen unterschiedlicher Typen erhebliche Probleme verursachen.
| Tabelle 2: Dateizeiten verschiedener Dateisysteme | ||||||
| VFS | ext2/3 | ext4 | FAT | exFAT | NTFS | |
| Bezugszeitpunkt | alt ab/vor JW 1969➔1970 | ab/vor JW 1969➔1970 | nur ab JW 1969➔1970 | nur ab JW 1969➔1970 | nur ab JW 1979➔1980 | nur ab 01.01.1601 12:00 |
| neu nur ab JW 1969➔1970 | ||||||
| Zeitraum | alt ≈ 1902 - 2038 neu bis ≈2555 | ≈ 1902 - 2038 | bis ≈2555 | bis Ende 2098 | bis Ende 2108 | bis ≈60100 |
| Anzahl Zeitstempel | 4 | 3 | 4 | 3 | 3 | 8 |
| Orts-/Weltzeit | Weltzeit | Weltzeit | Weltzeit | Ortszeit ohne Zeitzone | Ortszeit mit Zeitzone | Weltzeit |
| Auflösung | alt 1s neu 1ns | 1s | 1ns | create 10ms access 1d modify 2s | create 10ms access 2s modify 10ms | 100ns |
Die Abkürzung VFS meint das "Virtual File System" des Linux-Kernels
Die Abkürzung JW steht für Jahreswechsel.
Die Dateisysteme FAT und exFAT verwenden zur Speicherung der Zeiten strukturierte Felder; deshalb läßt sich bei diesen der jeweils mögliche Zeitraum leicht auf Jahresbasis exakt angeben. Die anderen Dateisysteme zählen einfach Ticks der jeweiligen Dauer ab dem Bezugszeitpunkt in einer 32- oder 64-bitigen Ganzzahl; bei einer Umrechnung in Jahre erfolgte aus praktischen Gründen eine Rundung.
Zeitstempel lassen sich natürlich manipulieren; unter Linux z.B. mit dem Befehl touch. Dieses Programm arbeitet z.B. bei NTFS fehlerhaft, da es manche zulässigen Zeiten nicht akzeptiert und manche unzulässigen Zeiten annimmt.
Die verschiedenen Dateisysteme realisieren Dateinamen für Ordner und Dateien (und ggf. weitere Dateitypen) auf unterschiedliche Art und Weise; daher gibt es für die zulässigen Dateinamen jeweils unterschiedliche Anforderungen, Eigenschafte und Einschränkungen.
Bei einem für UNIX-artige Betriebssysteme vorgesehenen Dateisystem wie beispielsweise ext können Dateinamen bis zu 255 Byte lang sein; dabei sind außer dem Wert 0 und dem Wert 0x2f (das ASCII-Zeichen /) jeder andere Wert zulässig. Das Dateisystem selbst interpretiert diese Bytefolgen in keiner Weise, sondern das geschieht erst durch das Betriebssystem gemäß der jeweils wirksamen Lokalisierung, die bei Ubuntu normalerweise auf UTF-8 basiert.
In Dateisystemen des Typs FAT (FAT12/16/32) gibt es üblicherweise für jede Datei einen oder zwei Dateinamen:
Jede Datei muss einen 8.3-Namen haben. Für diese maximal 11 Byte sind alle Zeichen aus einem einstellbaren 1-Byte-pro-Zeichen-Zeichensatz wie z.B. ISO-8859-1 außer den folgenden 14 Werten zulässig: . " / \ [ ] : ; | = , * ? und der Wert 0x20 (Leerzeichen). Außerdem muss der Name mit einem Buchstaben oder einer Zahl beginnen, und die Namen CON, AUX, COM1, COM2, COM3, COM4, LPT1, LPT2, LPT3, PRN, NUL sind unzulässig in allen Varianten bzgl. Groß- und Kleinbuchstaben. Wenn man einen Dateinamen verwendet, der nicht in dieses 8.3-Korsett passt, wird ein anschließend beschriebener langer Dateiname gespeichert und aus diesem nach einem festen, aber vom Betriebssystem abhängigen Algorithmus ein zulässiger 8.3-Name abgeleitet.
Jede Datei (ausgenommen in sehr alten Versionen) kann einen weiteren Namen bis zu 255 Zeichen bzw. 510 Byte langen Namen aus Unicode-Zeichen in der Codierung UTF-16LE (früher: UCS-2) haben. Jedes Zeichen belegt 2 oder in seltenen Fällen 4 Byte.
In Dateisystemen des Typs exFAT hat jede Datei genau einen bis zu 255 Zeichen bzw. 510 Byte langen Namen. Die Bytefolge wird als Folge von Unicode-Zeichen in der Codierung UTF-16LE (veraltet: UCS-2) interpretiert. Mit jedem Namen gelten aber auch alle durch unterschiedliche Groß-/Kleinschreibung aus diesem ableitbaren Synonyme als zulässige Namen für dieselbe Datei, d.h. für die Praxis: Man kann zwar Dateinamen in gemischter Groß-Kleinschreibung verwenden, aber zwei solche Synonyme können nicht gleichzeitig verwendet werden. Außerdem sind bestimmte Zeichen in Dateinamen generell unzulässig, und zwar die 9 Unicode-Zeichen " * / : < > ? \ | und die 32 Unicode-Positionen 0x0000 - 0x00iF.
In Dateisystemen des Typs NTFS müssen Dateien einen Namen und können beliebig viele weitere Namen haben. Jeder Name besteht aus bis zu 255 Unicode-Zeichen in der Codierung UTF-16LE. Lediglich die beiden Werte 0000 und 0x002f (das Zeichen /) dürfen diese Namen nicht enthalten. NTFS kennt aber auch eine optionale Betriebsart, in der einige von Windows unerwünschte Zeichen in Dateinamen unzulässig sind. Unter Windows ist diese Betriebsart immer aktiviert, unter Linux ist sie standardmäßig ausgeschaltet.
Unter Linux gelten die beschriebenen Einschränkungen des jeweiligen Dateisystemtyps, aber nicht notwendigerweise die Einschränkungen, welche Windows zusätzlich beachtet:
Linux unterscheidet auch bei einem Windows-Dateisystem konsequent Groß- und Kleinschreibung. Erika.JPG und erika.jpg sind in Linux zwei voneinander unabhängige Dateinamen, die im selben Ordner nebeneinander verwendet werden dürfen. In Windows ist dies nicht zulässig. Auch wenn Groß- und Kleinbuchstaben angezeigt werden, gelten in Windows beide Namen dennoch als identisch.
Windows verbietet bestimmte Sonderzeichen und weigert sich, diese in Dateinamen zu verwenden.
Windows verbietet die Dateinamen CON, AUX, COM1, COM2, COM3, COM4, LPT1, LPT2, LPT3, PRN, NUL.
Wenn man ein Windows-Dateisystem zum Datenaustausch zwischen Linux und Windows verwenden möchte, sollte man die zusätzlichen Einschränkungen von Windows beachten. Zur Erzwingung der Verwendung Windows-kompatibler Dateinamen dient unter NTFS die Mount-Option windows_names, welche UDisks[6] standardmäßig aktiviert, mount[1] jedoch nicht.
⚓︎ Zur Anpassung der unterschiedlichen Zeichensätze gibt es spezielle Mount-Optionen:
| Tabelle 3: Optionen für Zeichensätze | ||
| Option | Treiber | Wirkung |
codepage=CPnnn | msdosvfat | Angabe, wie die Zeichen in 8.3-Namen gelesen werden sollen. Als Wert muss die Codepage des Windows-Systems angegeben werden, welches die 8.3-Namen erzeugt hat. Oft ist dies CP850 oder CP437. |
iocharset=iso8859-1 | msdosvfatKernel ntfsntfs3 | Angabe, wie die UTF-16-Zeichen in langen Dateinamen in die vom Linux-System verwendeten Zeichensatz umgesetzt werden sollen. Dies ist insbesondere wichtig bei Verwendung eines 1-Byte-pro-Zeichensatzes wie z.B. ISO-8859-1. Ubuntu verwendet jedoch standardmäßig (seit Dapper Drake 6.06) den Mehrbyte-Zeichensatz Unicode mit der Codierung UTF-8. Eine Angabe wie iocharset=utf8 ist möglich, aber veraltet und missbilligt; man soll die Option utf8 verwenden. |
nls | Kernel ntfs | Veraltet. Ersetzt durch iocharset. |
utf8 | vfatKernel ntfs | Die UTF-16-Zeichen in langen Dateinamen unter Windows sollen in UTF-8-Zeichen unter Linux übersetzt werden. |
windows_names | ntfs3ntfs-3g | Erzwingt unter Linux einen zu Windows kompatiblen Dateinamen beim Anlagen einer neuen oder Umbenennen einer vorhandenen Datei. |
shortname=mixed | vfat | Steuert die Anzeige und die Vergabe von 8.3-Namen, die nur ersatzweise für fehlende lange Dateinamen angezeigt werden. Vorgabe ist mixed, welches die Namen wie tatsächlich gespeichert anzeigt. Weitere mögliche Werte sind lower für Anzeige in Kleinbuchstaben, win95 für Anzeige in Großbuchstaben und winnt für Anzeige wie gespeichert. In allen Fällen wird ein langer Name erzeugt, wenn der gewünschte Name nicht in das 8.3-Schema passt oder Kleinbuchstaben enthält oder nur bei winnt Klein- und Großbuchstaben mischt. |
ignore_case | lowntfs-3g | Nur relevant für die selten verwendete Variante lowntfs-3g von ntfs-3g. |
Linux und Windows haben unterschiedliche Methoden zur Kennzeichnung einer ausführbaren Datei:
Unter Linux kann jede Datei gestartet werden, welche gleichzeitig diese Voraussetzungen erfüllt:
Sie stammt von einem Dateisystem, welches mit der Option exec eingebunden wurde,
und sie gibt über ihre Rechte dem sie startenden Benutzer das Ausführungsrecht x.
Unter Windows ist jede Datei startfähig, wenn ihr Dateiname mit einem Suffix .bat, .com oder .exe endet.
Natürlich sollte jede als „ausführbar“ angezeigte Datei auch tatsächlich ein Skript oder Binärcode enthalten; anderenfalls endet der Startversuch mit einem Fehler.
Beim Einbinden eines Windows-Dateisystems unter Linux gelten natürlich die Regeln von Linux, jedoch besteht bei Windows-Dateisystemen die Besonderheit, dass die Dateirechte ja gar nicht existieren, sondern temporär simuliert werden. Dadurch können, je nach den konkreten Verhältnissen beim Einbinden, Nebeneffekte entstehen:
Dateien werden mit dem Recht „ausführbar“ angezeigt, obwohl sie kein Skript und auch keinen Binärcode enthalten.
Dateien werden mit dem Recht „ausführbar“ angezeigt, können aber trotzdem nicht gestartet werden.
Dateien mit tatsächlich ausführbarem Inhalt werden nicht als „ausführbar“ dargestellt.
Bereits in Windows installierte Programme können in der Regel unter Wine oder CrossOver ohne Neuinstallation nicht gestartet werden. Dagegen lassen sich portable Windows-Programme oftmals direkt durch einen Doppelklick auf die .exe-Datei mittels Wine oder CrossOver öffnen, was i.d.F. effektiv starten bedeutet.
Einem Dateisystem, welches als „nicht ausführbar“ eingebunden (Option noexec) wurde, fehlt in jedem Fall die Möglichkeit zur direkten Ausführung einer von ihr stammenden Datei. Um dies zu ändern, muss man das Dateisystem aushängen und erneut mit der Option exec einhängen (s.u.); Abziehen und erneutes Einstecken des Datenträgers reicht nicht aus.
Wird ein Datenträger mit einem Windows-Dateisystem als „ausführbar“ eingehängt (Option exec), dann können ggf. Windows-Schadprogramme von diesem Datenträger über Wine oder CrossOver ausgeführt werden und das Linux-System beschädigen.
Die Dateisysteme FAT12/16/32 und exFAT kennen abseits der in ihnen eingebauten Mechanismen für mehrdeutige Dateinamen immer nur einen Dateinamen pro Datei und unterstützen daher keine Hardlinks. Sie unterstützen auch keine symbolischen Verknüpfungen (Symlinks).
Das Dateisystem NTFS kennt dagegen mehrere Arten von Verknüpfungen:
Hardlinks sind zusätzliche, zum ersten Dateinamen gleichberechtigte Dateinamen. Sie können unter Linux mit dem Befehl ln angelegt werden und auch unter Linux wie gewohnt benutzt werden.
Softlinks bzw. Junctions unter Windows können unter Linux nicht kontrolliert angelegt werden. Unter Verwendung des Treibers ntfs3 mit einem Dateimanager wie z.B. Nautilus oder auf der Kommandozeile mit dem Befehl ln -s angelegte symbolische (!) Links scheinen technisch nicht den unter Linux üblichen Symlinks zu entsprechen, sondern verkappte (defekte?) Junctions ("reparse points") zu sein.
Symlinks können unter Linux sowohl bei Verwendung des Treibers ntfs3 als auch ntfs-3g auf der Kommandozeile mit dem Befehl ln -s angelegt werden und funktionieren unter Linux wie symbolische Links, sind aber abhängig vom Treiber und funktionieren mit dem anderen Treiber unter Linux nicht, und auch nicht unter Windows.
Wegen der Unterschiede der beiden Betriebssysteme und unter Linux mit den beiden Treibern wird dringend empfohlen:
Unter Linux auf Anlegen und Nutzung von Softlinks, Junctions und Symlinks innerhalb und aus NTFS heraus verzichten.
Unter Linux grundsätzlich nur einen der möglichen Treiber für NTFS benutzen.
Symbolische Verknüpfungen aus einem anderen Dateisystem, welches diesen speziellen Dateityp kennt (wie z.B. ext) zu Zielen in Windows-Dateisystemen sind uneingeschränkt erlaubt.
Die unter Windows üblichen Verknüpfungen über Dateien mit der Namenserweiterung lnk sind keine Eigenschaft des Dateisystems, sondern eine spezielle Arbeitsweise des Windows-Desktops. Im Dateisystem entsprechen diese Verknüpfungen normalen Dateien mit auf lnk endenden Dateinamen. Unter Linux kann man mit solchen Dateien gar nichts anfangen; außer man benutzt sie in einer sich wie Windows verhaltenden Shell wie Wine oder CrossOver – in diesen können sie je nach Dateiinhalt wie beabsichtigt funktionieren oder auch nicht.
Ein weiteres Problem kann die Interpretation von Ziffern in der Ordnungsstruktur sein. Während Windows auch Zahlen alphabetisch ordnet, ordnet sie Linux numerisch. Dateien können deshalb in Windows und Linux verschieden angeordnet erscheinen.
Für Windows-Dateisysteme sind beim Einhängen unter Linux grundsätzlich möglich diese Typbezeichnungen:
auto, msdos, vfat, exfat, exfat-fuse, ntfs, ntfs-3g, lowntfs-3g, ntfs3
Die mehrdeutigen Bezeichner auto und ntfs sollte man vermeiden:
auto steht für alles, was mit Windows zu tun hat sowie alles andere auch.
ntfs steht für das alte Modul im Kernel und auch für das FUSE-Programm ntfs-3g; das kann sich zukünftig ändern.
Die selten verwendete Variante lowntfs-3g von ntfs-3g wird in diesem Artikel ignoriert.
Beim Einbinden über UDisks mittels dessen Befehls udisksctl kann man msdos, vfat, exfat, ntfs, ntfs3 verwenden; wenn man nichts angibt, werden aber auch exfat-fuse und ntfs-3g automatisch verwendet, wenn ein Kernel-Modul scheitert oder nicht benutzt werden kann. Die mehrdeutige Angabe ntfs sollte man vermeiden.
Die beiden Treiber ntfs3 und ntfs-3g für NTFS können grundsätzlich zwar wechselweise benutzt werden, wegen unterschiedlichem Funktionsumfang und Implementierung mancher Features können sich dabei aber überraschende Verhaltensweisen und ggf. auch der Verlust von Datenbeständen ergeben. Es wird dringend empfohlen, sich für einen der beiden Treiber zu entscheiden und die Benutzung des anderen zu erschweren oder besser zu verhindern.
Vorstehender Abschnitt gilt grundsätzlich auch bzgl. der beiden Treiber exfat und exfat-fuse für exFAT; hier ist aber die Gefahr von Datenverlusten weniger brisant.
Man sollte sich als Anwender für jeweils eine Möglichkeit entscheiden und die andere sperren. Die persönliche Festlegung auf jeweils nur einen Treiber und Durchsetzung der Festlegung mittels organisatorischer und technischer Maßnahmen ist auch deshalb wichtig, weil unterschiedliche Versionen von Ubuntu die Treiber auch unterschiedlich bevorzugen.
Grundsätzlich sollte man in der Datei /etc/fstab[2] und bei Befehlen zur Einbindung immer einen konkreten Treiber angeben und die mehrdeutigen Typbezeichner auto und ntfs vermeiden.
Wer exfat benutzen möchte, sollte das Paket exfat-fuse nicht installieren oder deinstallieren.
Wer exfat-fuse einsetzen möchte, sollte ein automatisches Laden des Kernel Moduls exfat verbieten, indem man es auf die Sperrliste setzt. Damit für den Dateisystemtyp exFAT das zuständige Programm direkt gefunden wird, muss man einen symbolischen Link setzen:
sudo ln -s /sbin/mount.exfat-fuse /sbin/mount.exfat
Wer den alten Kernel Modul ntfs nicht benutzen möchte, kann auch diesen Modul auf die Sperrliste setzen.
Wer ntfs-3g verwenden will, sollte ein automatisches Laden des Kernel Moduls ntfs3 verbieten, indem man es auf die Sperrliste setzt.
Wer ntfs3 benutzen möchte, kann die Benutzung von ntfs-3g über zwei Methoden ausschließen:
Entweder: Das Paket ntfs-eg deinstallieren. Nachteil dieser Methode: Man verliert auch die Dienstprogramme und kann nicht mehr eine Partition als NTFS formatieren oder ein solches Dateisystem überprüfen oder pflegen.
Oder: Das Paket behalten, aber dem Programm /bin/ntfs-3g die Ausführungsrechte entziehen. Nachteil hierbei: Bei einem Update kann diese Datei wieder die Ausführungsrechte erhalten.
Ab Ubuntu 23.10 kann man für alle Einbindungen, welche über den Disk Manager UDisks[6] erfolgen, in dessen Konfigurationsdatei spezifisch für jeden Dateisystemtyp den zu verwendenden Treiber festlegen. Das gilt dann auch für alle grafischen Programme des Desktops.
⚓︎ Man setzt einen Kernel Modul auf die Sperrliste, indem man als Administrator im Ordner /etc/modprobe.d/ eine Datei ähnlich folgendem Beispiel anlegt:
# /etc/modprobe.d/blacklist-msfs.conf blacklist ntfs blacklist ntfs3 blacklist exfat
Man kann mit dieser Methode nur ladbare Kernel Module sperren, also nicht das fest im Kernel eingebaute vfat und auch kein FUSE-Programm.
Das einzubindende Dateisystem darf nicht von einem anderen, ggf. schlafenden Betriebssystem benutzt werden.
Generell darf man ein Dateisystem nur dann mit Schreibzugriff (rw) einbinden, wenn es nicht von einem anderen Betriebssystem aus eingebunden ist!
Dieser Grundsatz gilt natürlich auch für Windows-Dateisysteme, hat aber bei wechselnder Benutzung des Dateisystems unter Windows und Linux seine besondere Brisanz. Windows fährt nämlich nicht immer vollständig herunter, sondern wechselt gerne in einen Ruhezustand, in dem das Dateisystem nicht freigegeben wird. Beim Schreiben in ein solches noch von anderer Seite belegtes Dateisystem ist Datenverlust möglich und sogar nahezu sicher.
Zur Vermeidung dieses Verhaltens kann unter Windows ein Administrator (Mitglied der Gruppe Administratoren unter Windows) den Ruhezustand verbieten:
powercfg /h off
Ein Update/Upgrade von Windows entsperrt aber möglicherweise den Ruhezustand wieder.
Bei NTFS kann diese bestehende Verbindung zu einem anderen Betriebssystem erkannt werden; wenn Linux es erkennt – was nicht immer zutrifft! – verweigert es dann eine Einbindung mit Schreibzugriff und bindet im Lesemodus (ro) ein. Bei den anderen Dateisystemtypen muss man selber auf die Konsistenz des Dateisystems achten und das Dateisystem immer vor der Abtrennung des Datenträgers aus binden oder auswerfen. Diese Praxis sollte man auch bei NTFS beachten, da die automatische Erkennung der noch bestehenden Einbindung in einem anderen schlafenden Betriebssystem nicht immer zuverlässig funktioniert; bei Windows wohl nur für das Laufwerk C:.
Beim Einbinden über eine Desktop-Umgebung wird im Hintergrund der Disk Manager UDisks[6] verwendet. Der Benutzer eines grafischen Programms hat keinerlei direkten Einfluss auf den beim Aufruf des Disk Managers verwendeten Parameter und Mount-Optionen, allerdings kann der Disk Manager selbst konfiguriert werden, oder man kann bekannte Dateisysteme in fstab[2] eintragen. Insbesondere beim Dateisystemtyp NTFS kann dies für eine ordnungsgemäße Funktion erforderlich sein.
Windows-Dateisysteme lassen sich unter Linux mit den gleichen Methoden wie sonst unter Linux übliche Dateisysteme einbinden:
Bei Verwendung eines grafischen Desktops werden im Betrieb hinzu gesteckte Datenträger automatisch eingebunden oder können manuell über Bedienelemente in der GUI, Programme wie Laufwerke (gnome-disks) oder Dateimanager eingebunden werden. Dabei arbeitet im Untergrund der Disk Manager UDisks, welcher auch per Kommandozeile angesprochen werden kann und ggf. zur Autorisierung das Passwort eines Administrators erfragt. Dabei ergibt sich dasselbe Ergebnis wie bei einem entsprechende Aufruf von udisksctl.
Über das Kommandozeilenprogramm udisksctl kann UDisks ebenfalls angesprochen werden und berücksichtigt dann eine passende Zeile in der Datei fstab, seine eigene Konfiguration und ggf. als Argumente übergebene Angaben des Dateisystemtyps und zu den Mount-Optionen.
Andere Programm wie beispielsweise mount[1], gio mount oder systemd-mount sind ebenfalls wie gewohnt einsetzbar.
Beim Hochlauf des Systems werden die in der Datei fstab alle ohne Option noauto eingetragenen Dateisysteme automatisch eingebunden. Wenn dies bei einem Dateisystem misslingt und keine ordentliche Fehlerbehandlung erfolgt, stoppt der Systemstart mit einer Kernal-Panik.
Jeder Benutzer kann in der Datei fstab mit der Option user oder users eingetragene Dateisysteme mit dem Befehl mount[1] einhängen. Bei den mit FUSE einzuhängenden Dateisystemen wie z.B. exfat-fuse und ntfs-3g ist ab Ubuntu 22.04 eine solche Markierung mit user oder users nicht mehr erforderlich.
Das Ergebnis einer Einbindung lässt sich mit dem Befehl findmnt kontrollieren, welcher auch Filterung und Formatierung beherrscht, Beispiel:
findmnt -t vfat,exfat,ntfs3,fuseblk -o SOURCE,TARGET,FSTYPE,VFS-OPTIONS,FS-OPTIONS | cat
Die Besitzer, Gruppen und Zugriffsrechte zu den einzelnen Dateien zeigt dieser Befehl an:
ls -al /media/XXX/
Dabei ist natürlich der Einbindepunkt anzupassen.
Beim automatischen Einhängen mittels UDisks ohne eigene Konfiguration gelten die in der Datei /etc/udisks2/mount.options.conf.example aufgeführten Standards; in der Praxis (getestet mit Ubuntu 20.04, 22.04 und 24.04) ergeben sich diese Ergebnisse:
bei Nutzung eines Treibers im Kernel (vfat, exfat, ntfs3):
SOURCE TARGET FSTYPE VFS-OPTIONS FS-OPTIONS /dev/sdb2 /media/klaus/USB-FAT vfat rw,nosuid,nodev,relatime rw,uid=1000,gid=1000,fmask=0022,dmask=0022,codepage=437,iocharset=iso8859-1,shortname=mixed,showexec,utf8,flush,errors=remount-ro /dev/sdb3 /media/klaus/USB-exFAT exfat rw,nosuid,nodev,relatime rw,uid=1000,gid=1000,fmask=0022,dmask=0022,iocharset=utf8,errors=remount-ro /dev/sdb4 /media/klaus/USB-NTFS ntfs3 rw,nosuid,nodev,relatime rw,uid=1000,gid=1000,windows_names,iocharset=utf8
Der einbindende Benutzer bzw. der angemeldete Benutzer (meist mit der UID 1000) wird zum temporären Besitzer von Dateien und kann diese auch lesen und in sie schreiben, andere haben nur lesenden Zugriff. Bei NTFS werden aber bereits den Dateien zugeordnete Linux-Besitzer, -Gruppe und -Dateirechte übernommen.
bei Nutzung eines FUSE-Programms (exFAT-fuse, ntfs-3g):
SOURCE TARGET FSTYPE VFS-OPTIONS FS-OPTIONS /dev/sdb3 /media/klaus/USB-exFAT fuseblk rw,nosuid,nodev,relatime rw,user_id=0,group_id=0,default_permissions,allow_other,blksize=4096 /dev/sdb4 /media/klaus/USB-NTFS fuseblk rw,nosuid,nodev,relatime rw,user_id=0,group_id=0,default_permissions,allow_other,blksize=4096
Auch hierbei wird der einbindende Benutzer bzw. der angemeldete Benutzer zum temporären Besitzer der Dateien. Anders als bei den Kernel Modulen erhalten aber auch alle anderen Vollzugriff. Siehe: Temporär simulierte Dateirechte. Allerdings werden beim Zugriff auf eine Datei ja auch noch die Zugriffsrechte auf die Order im Pfad beachtet, wodurch z.B. bei Verwendung eines benutzerspezifischen Einbindepunktes unter /media/$USER/ in der Praxis nur der einbindende Benutzer zugreifen kann.
Beim Einhängen durch Bedienung in der GUI gelten ohne eigene Konfiguration die vorstehenden Ausführungen ebenfalls.
Eine Einbindung durch Bedienung im Terminal[4] kann man verschiedene Programme verwenden, empfohlen wird udisksctl mount[6]. Beispiel:
udisksctl mount -b /dev/sdb3
Einzelheiten siehe UDisks (Abschnitt „Dienstprogramm-udisksctl“)
Beim manuellen Einhängen kann man die hier anschließend verwendeten minimalen Mount-Optionen ergänzen um weitere allgemeine Optionen für die Datei fstab[2] und durch spezielle Optionen für den jeweiligen Typ, siehe dazu die in Tabelle 1 genannten speziellen Artikel. In der Praxis sind oft die in Tabelle 3 genannten Optionen zur Anpassung der Behandlung von Dateinamen wichtig.
Man kann für manuelles Einhängen als normaler Benutzer (siehe Non-superuser mounts in der Manpage von mount) optional eine Konfigurationszeile in der Datei fstab[2] ähnlich folgenden Beispielen verwenden:
bei Nutzung eines Treibers im Kernel (vfat, exfat, ntfs3):
/dev/sdb1 /media/NTFS ntfs3 noauto,nodev,noexec,dmask=0770,fmask=0771 /dev/sdb2 /media/FAT vfat noauto,users /dev/sdb3 /media/exFAT exfat noauto,users /dev/sdb4 /media/tmp ntfs3 noauto,users
Diese liefern bei einer Bedienung in der GUI oder mit dem Befehl udisksctl diese Ergebnisse:
SOURCE TARGET FSTYPE VFS-OPTIONS FS-OPTIONS /dev/sdb1 /media/NTFS ntfs3 rw,nodev,noexec,relatime rw,uid=0,gid=0,dmask=0770,fmask=0771,iocharset=utf8 /dev/sdb2 /media/FAT vfat rw,nosuid,nodev,noexec,relatime rw,uid=1000,gid=1000,fmask=0022,dmask=0022,codepage=437,iocharset=iso8859-1,shortname=mixed,errors=remount-ro /dev/sdb3 /media/exFAT exfat rw,nosuid,nodev,noexec,relatime rw,uid=1000,gid=1000,fmask=0022,dmask=0022,iocharset=utf8,errors=remount-ro /dev/sdb4 /media/tmp ntfs3 rw,nosuid,nodev,noexec,relatime rw,uid=1000,gid=1000,iocharset=utf8
Die Optioen nodev und noexec (impliziert nosuid) oder wenigstens nosuid schließen Scheunentore für Schadsoftware und sollten daher immer angegeben werden; auf die explizite Angabe kann verzichten, wer user oder users angibt, da user die Optionen nodev,nosuid,noexec impliziert.
Die Beispiele zu NTFS zeigen zwei unterschiedliche Methoden, um dem die Einbindung auslösenden Benutzer Lese- und Schreibrechte zu geben:
Mit der Option user oder users (wie bei sdb4) wird der die Einbindung auslösende Benutzer auch zum die Einbindung durchführenden Benutzer und damit zum temporären Besitzer der Dateien.
Ohne eine solche Option (wie bei sdb1) erfolgt die Einbindung durch root und dieser wird zum Besitzer aller Dateien. Zusätzlich bestimmt man über Umask-Werte für Ordner und Dateien explizit die Dateirechte für „alle anderen“. Diese Methode ist auch bei Dateisystemen der Typen FAT und exFAT möglich.
Die Angaben user & Co. sind keine Mount-Optionen, sondern Anweisungen an das Programm mount und weitere Programme, welche die Datei fstab auswerten. Sie modifizieren die Arbeitsweise dieser Programme und der von diesen aufgerufenen Funktionen. Außerdem sind ihre Nebenwirkungen relevant für das Ergebnis des Prozesses.
Die VFS-Option relatime entspricht einer Vorgabe und ist in den meisten Fällen zweckmäßig. Dies gilt ebenso für die für den Dateisystemtyp spezifischen Optionen zur Übersetzung der Dateinamen.
Die oben vorgestellten Zeilen in der Datei fstab kann man auch mit dem Programm mount[1] verwenden.
Für die FUSE-Programme kann man in der Datei fstab ähnliche Konfigurationszeilen verwenden:
/dev/nvme0n1p7 /media/NTFS ntfs-3g noauto,nodev,noexec /dev/nvme0n1p19 /media/exFAT exfat-fuse noauto,nodev,noexec
Dabei kann man hier auf die Angabe einer Option user verzichten und sollte auch darauf verzichten, denn mit ntfs-3g wurden mit user Fehlfunktionen berichtet.
Diese Konfigurationszeilen führen bei einer Bedienung in der GUI oder über das Kommandozeilenprogramm udisksctl zu diesen Ergebnissen:
SOURCE TARGET FSTYPE VFS-OPTIONS FS-OPTIONS /dev/nvme0n1p19 /media/exFAT fuseblk rw,nosuid,nodev,relatime rw,user_id=0,group_id=0,default_permissions,allow_other,blksize=4096 /dev/nvme0n1p7 /media/NTFS fuseblk rw,nodev,noexec,relatime rw,user_id=0,group_id=0,allow_other,blksize=4096
Der Dateisystemtreiber von exfat-fuse ignoriert die meisten (außer ro alle?) über die Datei fstab gesetzten Optionen und ersetzt sie durch eigene.
Alle Dateien gehören root, aber alle anderen können sie lesen und in sie schreiben.
Die Angabe user ändert nichts bei exfat-fuse, führt aber bei ntfs-3g zum Scheitern.
Die o.g. Konfigurationszeilen für ntfs-3g und exfat-fuse funktionieren nicht bei einer Verwendung mit mount als normaler Benutzer (non-superuser mount), aber natürlich in Kombination mit sudo und auch beim Rechnerstart. Experten können die speziellen für FUSE-Programme benötigten Berechtigungen einstellen, obwohl diese die Sicherheit des Systems reduzieren.
Bei Verwendung der Typbezeichnung exfat-fuse oder ntfs-3g müssen bei einer Einbindung mittels mount durch einen normalen Benutzer (non-superuser-mount) diese drei Bedingungen erfüllt sein:
Beim jeweils einbindenden Programm /sbin/exfat-fuse bzw. /bin/ntfs-3g muss SUID root gesetzt sein.
Der einbindende Benutzer muss für den Einbindepunkt das Lese- und das Schreibrecht haben.
Der einbindende Benutzer muss für die Gerätedatei des Blockgerätes /dev/… mindestens das Lese-, besser auch das Schreibrecht haben. (Insbesondere diese Bedingung ermöglicht versehentliche und absichtliche Schädigung des Dateisystems!)
Die vorstehenden drei Bedingungen gelten für jedes FUSE-Programm und somit grundsätzlich auch für exfat-fuse, jedoch ist dieses im Gegensatz zu beispielsweise ntfs-3g smart genug, selbst für die Erfüllung der Bedingungen 2 und 3 zu sorgen, sobald man das SUID-Bit gesetzt hat.
Für die meisten Anwender ist sinnvoller, bei der Verwendung von FUSE-Programmen auf die Einbindung per mount durch normale Benutzer zu verzichten.
Dafür benötigt man eine Zeile in der Datei fstab, dies kann man ableiten aus den im Abschnitt Manuelles Einhängen genannten Beispielen, wenn man die Mount-Option noauto durch nofail ersetzt.
Für die Wartung eines FAT-Dateisystems benötigt man das Paket dosfstools, welches bei Ubuntu zur Standardinstallation gehört und u.a. die in folgender Tabelle genannten Befehle enthält:
| Befehl | Beschreibung |
mkfs.fatmkfs.vfatmkfs.msdosmkdosfs | Formatiert eine Partition mit einem FAT-Dateisystem. Der genaue Typ FAT12/FAT16/FAT32 wird automatisch aus der Größe der Partition oder angegebenen Optionen bestimmt. Beispiel: sudo mkfs.fat -v -F 16 /dev/sda1 |
fsck.fatfsck.vfatfsck.msdosdosfsck | Überprüft und repariert nötigenfalls ein FAT-Dateisystem; dieses darf nicht eingehängt sein. Beispiel: sudo fsck.fat -v /dev/sda2 |
fatlabeldosfslabel | Zeigt das Label eines FAT-Dateisystems an und erlaubt es, dieses zu verändern. |
Der jeweils zuerst angegebene Name ist der originale Dateiname des Programms, die weiteren über Symlinks realisierte Aliase; die Wahl des Namens hat keinerlei Einfluss auf das Ergebnis. Alle Programme benötigen Rootrechte[4][5] wegen des direkten Zugriffs auf die Gerätedatei im Ordner /dev/.
Die Befehle kennen etliche, meist nicht benötigte Optionen, die man bei Bedarf in der jeweiligen Manpage nachlesen kann.
Mit dem Paket dosfstools lassen sich keine Startmedien nach Bios-Boot-Spezifikation formatieren. Unter Linux benötigt man diese Funktionalität auch nicht. Wer aber dennoch unter Linux solche Startmedien erstellen möchte, kann das Paket mtools installieren, welches allerdings ohne Einbindung in das VFS direkt auf die Geräte zugreift.
Für die Wartung eines Dateisystems vom Typ exFAT benötigt man das Paket exfat-progs, siehe Artikel exFAT.
Für die Wartung von NTFS-Partitionen gibt es die Tool-Sammlung ntfsprogs, die bei Ubuntu seit der Version 2011.4.12 (Ubuntu 11.10) im Paket ntfs-3g integriert ist. Man benötigt daher dieses Paket auch bei der Verwendung des Kernel Moduls ntfs3. Siehe Artikel NTFS-3G.
Für den Austausch von Dateien zwischen einem Windows- und einem Linux-Betriebssystem sind alle verfügbaren Typen grundsätzlich geeignet. Man kann daher beispielsweise nach folgenden Kriterien auswählen.
FAT wird nahezu immer unterstützt, erlaubt aber nur kleine Dateien unter 4 GiB. Für manche Multimedia-Anwendungen daher ungeeignet.
exFAT wird weniger breit unterstützt, ist aber trotzdem eine gerne gewählte Alternative für FAT und kennt keine in der Praxis wichtige Größenbeschränkung für Dateien.
FAT und exFAT ermöglichen keine Zugriffskontrolle. Dies kann sowohl von Vorteil sein, weil dann auch nichts derartiges konfiguriert werden muss, aber in anderes Situationen auch ein Nachteil, wenn eine derartige Funktionalität verlangt wird.
NTFS ermöglicht eine Zugriffskontrolle auf der Linux-Seite, die allerdings (bei ntfs-3g) auch konfiguriert werden muss oder (bei ntfs3) nicht auf die Windows-Seite durchgreift.
FAT und exFAT bieten im Gegensatz zu NTFS keine Sicherheit für die Datenintegrität durch ein Journal.
Defekte FAT und exFAT Dateisysteme können auch unter Linux repariert werden, bei NTFS sollte man hierfür ein Windows bereithalten.
Ordner in Dateisystemen der Typen FAT oder exFAT können grundsätzlich auch für den Zugriff über das Netzwerk per NFS oder SMB freigegeben werden, jedoch eignen sich diese Dateisysteme nicht gut dafür, weil sie dem Betriebssystem keinerlei Unterstützung für die dabei für die Integrität der Daten benötigten Sperren bieten. FAT und exFAT fehlen permanente Inode-Nummern (siehe FAQ 🇬🇧 auf nfs.sourceforge.net).
Man sollte beachten:
FAT und exFAT nach Möglichkeit nur für lesenden Zugriff über das Netzwerk freigeben.
Wenn schreibender Zugriff benötigt wird, diesen auf einen Benutzer/Prozess beschränken.
Bei der Einbindug die Mount-Option nfs= für FAT entsprechend der eigenen Situation benutzen.
Bei der Freigabe eines Ordners in einem Dateisystems des Tps NTFS gibt es keine besonderen Vorgaben; sowohl ntfs3 wie auch ntfs-3g benennen explizit die Netzwerktauglichkeit in ihrer Dokumentation.
Partitionierung – Erstellen und Verändern von Partitionen
MS-Windows Integration: Hinweise zum Parallel-Betrieb von Linux und Windows auf einem Rechner oder in einem Netzwerk.
Externe Laufwerke statisch einbinden – Einbindung per UUID oder Label
Linux-Partitionen unter Windows – Der umgekehrte Weg: Linux-Partitionen in Windows verwenden.
vfat-tipps: 🇩🇪 Pro-Linux: Tipps zum vfat-Dateisystem unter Linux mit praktischen Anwendungsbeispielen vom 17.01.2005
NTFS-3G in Wikipedia
https://learn.microsoft.com/en-us/windows/win32/fileio/filesystem-functionality-comparison 🇬🇧
FAT 🇬🇧 – Technische Referenz (Microsoft FAT)