Fstab - Versionsgeschichte

Dirk am 12. November 2025 um 05:38 Uhr

2025-11-12T05:38:42Z

← Nächstältere Version		Version vom 12. November 2025, 07:38 Uhr
Zeile 43:		Zeile 43:
	Zum Mounten eines Dateisystems muss man dessen Typ angeben. Es besteht zudem die Möglichkeit der automatischen Erkennung. Durch die Verwendung von ''FUSE'' (zum Beispiel [[Sshfs\|SSHFS]]) können weitere Optionen verfügbar werden. Hierzu ist die Dokumentation des jeweiligen FUSE-Moduls konsultieren.		Zum Mounten eines Dateisystems muss man dessen Typ angeben. Es besteht zudem die Möglichkeit der automatischen Erkennung. Durch die Verwendung von ''FUSE'' (zum Beispiel [[Sshfs\|SSHFS]]) können weitere Optionen verfügbar werden. Hierzu ist die Dokumentation des jeweiligen FUSE-Moduls konsultieren.

	{\| ~~{{prettytable}}~~ class="sortable"		{\| class="wikitable sortable"
	\|-		\|-
	! Typ		! Typ
Zeile 107:		Zeile 107:
	Über die Optionen wird der Zugriff auf das jeweilige Dateisystem gesteuert. Mehrere Optionen werden durch Kommata ohne Leerzeichen getrennt.		Über die Optionen wird der Zugriff auf das jeweilige Dateisystem gesteuert. Mehrere Optionen werden durch Kommata ohne Leerzeichen getrennt.

	{\| ~~{{prettytable}}~~ class="sortable"		{\| class="wikitable sortable"
	\|-		\|-
	! Option		! Option

Dirk: /* Typ */ reiserfs ist mit 6.13 nicht mehr im Kernel

2025-01-22T10:07:51Z

Typ: reiserfs ist mit 6.13 nicht mehr im Kernel

← Nächstältere Version		Version vom 22. Januar 2025, 12:07 Uhr
Zeile 76:		Zeile 76:
	\| Microsoft NTFS		\| Microsoft NTFS
	\| {{ic\|ntfs-3g}} bietet [[Schreibzugriff mit ntfs-3g\|Schreibzugriff]]		\| {{ic\|ntfs-3g}} bietet [[Schreibzugriff mit ntfs-3g\|Schreibzugriff]]
	\|-
	~~\| {{ic\|reiserfs}}~~
	~~\| Reiser FS~~
	~~\| Für das Einbinden von Reiser FS 1 bis 3~~
	\|-		\|-
	\| {{ic\|swap}}		\| {{ic\|swap}}

Tuxnix: Kategorie:Konfiguration

2021-03-28T18:03:11Z

Kategorie:Konfiguration

← Nächstältere Version		Version vom 28. März 2021, 20:03 Uhr
Zeile 216:		Zeile 216:

	[[Kategorie:Konfiguration]]		[[Kategorie:Konfiguration]]
	~~[[Kategorie:Installation]]~~
	[[Kategorie:Grundlagen]]		[[Kategorie:Grundlagen]]
	[[en:fstab]]		[[en:fstab]]

Tuxnix: /* Optionen */

2020-10-02T19:19:57Z

Optionen

← Nächstältere Version		Version vom 2. Oktober 2020, 21:19 Uhr
Zeile 184:		Zeile 184:
	\| n/a		\| n/a
	\| Automatisches Einbinden durch systemd beim ersten Zugriff. Optimal bei Dateisystemen, die das Booten sehr verzögern können (SSHFS, NFS, etc.)		\| Automatisches Einbinden durch systemd beim ersten Zugriff. Optimal bei Dateisystemen, die das Booten sehr verzögern können (SSHFS, NFS, etc.)
			\|-
			\| {{ic\|nofail}}
			\| n/a
			\| Gibt keine Fehlermeldung aus und bootet auch dann wenn das Laufwerk nicht angeschlossen ist.
	\|-		\|-
	\| {{ic\|discard}}		\| {{ic\|discard}}

Kr1ss: /* Optionen */ kleine Ergänzung zu noatime/nodiratime bzgl. der gegenteiligen Optionen sowie Empfehlung zur Nutzung bei Btrfs i.V.m. Snapshots

2018-09-15T20:51:56Z

Optionen: kleine Ergänzung zu noatime/nodiratime bzgl. der gegenteiligen Optionen sowie Empfehlung zur Nutzung bei Btrfs i.V.m. Snapshots

← Nächstältere Version		Version vom 15. September 2018, 22:51 Uhr
Zeile 170:		Zeile 170:
	\|-		\|-
	\| {{ic\|noatime}}		\| {{ic\|noatime}}
	\| ~~n/a~~		\| {{ic\|atime}}
	\| Keine Zugriffszeiten für Dateien und Verzeichnisse ({{ic\|nodiratime}} wird durch {{ic\|noatime}} impliziert und muss nicht zusätzlich gesetzt werden) in der Inodetabelle speichern. Dies reduziert die ~~Datenträgerzugriffe,~~ und wird für SSDs empfohlen.		\| Keine Zugriffszeiten für Dateien und Verzeichnisse ({{ic\|nodiratime}} wird durch {{ic\|noatime}} impliziert und muss nicht zusätzlich gesetzt werden) in der Inodetabelle speichern. Dies reduziert die Datenträger-Schreibzugriffe und wird für SSDs empfohlen sowie, falls Snapshots genutzt werden sollen, für Btrfs.
	\|-		\|-
	\| {{ic\|nodiratime}}		\| {{ic\|nodiratime}}
	\| ~~n/a~~		\| {{ic\|diratime}}
	\| Keine Zugriffszeiten für Verzeichnisse in der Inodetabelle speichern. Dies reduziert die Datenträgerzugriffe.		\| Keine Zugriffszeiten für Verzeichnisse in der Inodetabelle speichern. Dies reduziert die Datenträgerzugriffe.
	\|-		\|-

NorPhi: Auftrennung von noatime und nodiratime in der Optionstabelle. nodiratime wird durch noatime impliziert und muss nicht extra gesetzt werden. Trotzdem sieht man oft genug beide angaben in einer fstab (redundante Optionen -> Verwirrung).

2018-09-12T19:13:31Z

Auftrennung von noatime und nodiratime in der Optionstabelle. nodiratime wird durch noatime impliziert und muss nicht extra gesetzt werden. Trotzdem sieht man oft genug beide angaben in einer fstab (redundante Optionen -> Verwirrung).

← Nächstältere Version		Version vom 12. September 2018, 21:13 Uhr
Zeile 169:		Zeile 169:
	\| Spezialfall bei FAT-Dateisystemen. Jeder Benutzer darf auf der Partition lesen und schreiben		\| Spezialfall bei FAT-Dateisystemen. Jeder Benutzer darf auf der Partition lesen und schreiben
	\|-		\|-
	\| {{ic\|noatime~~}}/{{ic\|nodiratime~~}}		\| {{ic\|noatime}}
	\| n/a		\| n/a
	\| Keine Zugriffszeiten für Dateien/Verzeichnisse in der Inodetabelle speichern. Dies reduziert die Datenträgerzugriffe, und wird für SSDs empfohlen.		\| Keine Zugriffszeiten für Dateien und Verzeichnisse ({{ic\|nodiratime}} wird durch {{ic\|noatime}} impliziert und muss nicht zusätzlich gesetzt werden) in der Inodetabelle speichern. Dies reduziert die Datenträgerzugriffe, und wird für SSDs empfohlen.
			\|-
			\| {{ic\|nodiratime}}
			\| n/a
			\| Keine Zugriffszeiten für Verzeichnisse in der Inodetabelle speichern. Dies reduziert die Datenträgerzugriffe.
	\|-		\|-
	\| {{ic\|1=errors=remount-ro}}		\| {{ic\|1=errors=remount-ro}}

Boenki: interwikilink

2014-01-25T17:38:13Z

interwikilink

← Nächstältere Version		Version vom 25. Januar 2014, 19:38 Uhr
Zeile 183:		Zeile 183:
	\| {{ic\|discard}}		\| {{ic\|discard}}
	\| n/a		\| n/a
	\| Bei Verwendung von SSDs um [~~https~~:~~//wiki.archlinux.org/index.php/~~Solid_State_Drives#TRIM TRIM] zu verwenden		\| Bei Verwendung von SSDs um [[:en:Solid_State_Drives#TRIM\|TRIM]] zu verwenden
	\|}		\|}

Dirk: /* Optionen */ typo

2014-01-25T15:05:48Z

Optionen: typo

← Nächstältere Version		Version vom 25. Januar 2014, 17:05 Uhr
Zeile 183:		Zeile 183:
	\| {{ic\|discard}}		\| {{ic\|discard}}
	\| n/a		\| n/a
	\| Bei ~~verwendung~~ von SSDs um [https://wiki.archlinux.org/index.php/Solid_State_Drives#TRIM TRIM] zu verwenden		\| Bei Verwendung von SSDs um [https://wiki.archlinux.org/index.php/Solid_State_Drives#TRIM TRIM] zu verwenden
	\|}		\|}

Dirk: /* Optionen */ discard für TRIM

2014-01-25T14:27:03Z

Optionen: discard für TRIM

← Nächstältere Version		Version vom 25. Januar 2014, 16:27 Uhr
Zeile 180:		Zeile 180:
	\| n/a		\| n/a
	\| Automatisches Einbinden durch systemd beim ersten Zugriff. Optimal bei Dateisystemen, die das Booten sehr verzögern können (SSHFS, NFS, etc.)		\| Automatisches Einbinden durch systemd beim ersten Zugriff. Optimal bei Dateisystemen, die das Booten sehr verzögern können (SSHFS, NFS, etc.)
			\|-
			\| {{ic\|discard}}
			\| n/a
			\| Bei verwendung von SSDs um [https://wiki.archlinux.org/index.php/Solid_State_Drives#TRIM TRIM] zu verwenden
	\|}		\|}

Boenki am 12. Januar 2014 um 20:31 Uhr

2014-01-12T20:31:27Z

← Nächstältere Version		Version vom 12. Januar 2014, 22:31 Uhr
Zeile 25:		Zeile 25:
	Das Dateisystem ist entweder ein ''Label'', die ''UUID'', die [[Gerätedatei]], oder ein weiteres definiertes Stichwort.		Das Dateisystem ist entweder ein ''Label'', die ''UUID'', die [[Gerätedatei]], oder ein weiteres definiertes Stichwort.

	Das Label des Dateisystems kann beim Erstellen, oder nachträglich mit entsprechenden Tools gesetzt werden. Für ext-Dateisysteme (ext2/3/4) zum Beispiel ist dies {{paket\|e2label}}. Die UUID wird beim Erstellen automatisch generiert, und ist über das Programm {{paket\|blkid}} abrufbar.		Das Label des Dateisystems kann beim Erstellen, oder nachträglich mit entsprechenden Tools gesetzt werden. Für ext-Dateisysteme (ext2/3/4) zum Beispiel ist dies {{paket\|e2fsprogs\|e2label}}. Die UUID wird beim Erstellen automatisch generiert, und ist über das Programm {{paket\|util-linux\|blkid}} abrufbar.

	Die Gerätedatei für die ~~Jeweilige~~ Partition kann sich unter gewissen Umständen ändern. Eine Partition, die unter {{ic\|/dev/sdb1}} erreichbar ist, könnte nach einem Start zum Beispiel unter {{ic\|/dev/sdc1}} verfügbar sein. Dies passiert für gewöhnlich allerdings nur, wenn man Partitionen (neu) einrichtet, alte Hardware um-, oder neue Hardware einbaut, sich die Zugriffs-Routinen ändern, oder der verbaute Controller diesbezüglich ein merkwürdiges Verhalten zeigt.		Die Gerätedatei für die jeweilige Partition kann sich unter gewissen Umständen ändern. Eine Partition, die unter {{ic\|/dev/sdb1}} erreichbar ist, könnte nach einem Start zum Beispiel unter {{ic\|/dev/sdc1}} verfügbar sein. Dies passiert für gewöhnlich allerdings nur, wenn man Partitionen (neu) einrichtet, alte Hardware um-, oder neue Hardware einbaut, sich die Zugriffs-Routinen ändern, oder der verbaute Controller diesbezüglich ein merkwürdiges Verhalten zeigt.

	Es ist immer ratsam, UUIDs oder Labels zu verwenden, weil man damit einfach „auf der sicheren Seite“ ist.		Es ist immer ratsam, UUIDs oder Labels zu verwenden, weil man damit einfach „auf der sicheren Seite“ ist.
Zeile 163:		Zeile 163:
	\| {{ic\|users}}		\| {{ic\|users}}
	\| n/a		\| n/a
	\| Jeder Benutzer darf das Gerät einhängen und ~~Aushängen~~		\| Jeder Benutzer darf das Gerät einhängen und aushängen
	\|-		\|-
	\| {{ic\|1=user,rw,umask=000}}		\| {{ic\|1=user,rw,umask=000}}
Zeile 179:		Zeile 179:
	\| {{ic\|noauto,x-systemd.automount}}		\| {{ic\|noauto,x-systemd.automount}}
	\| n/a		\| n/a
	\| Automatisches Einbinden durch ~~Systemd~~ beim ersten Zugriff. Optimal bei Dateisystemen, die das Booten sehr verzögern können (SSHFS, NFS, etc.)		\| Automatisches Einbinden durch systemd beim ersten Zugriff. Optimal bei Dateisystemen, die das Booten sehr verzögern können (SSHFS, NFS, etc.)
	\|}		\|}

Zeile 188:		Zeile 188:
	Die Pass-Anweisung wird vom Dateisystem-Test ausgewertet und definiert, in welcher Reihenfolge die Dateisysteme geprüft werden sollen. 0 = Keine Überprüfung, 1 = wird zuerst überprüft, 2 = wird überprüft nachdem alle mit 1 markierten Dateisysteme überprüft wurden.		Die Pass-Anweisung wird vom Dateisystem-Test ausgewertet und definiert, in welcher Reihenfolge die Dateisysteme geprüft werden sollen. 0 = Keine Überprüfung, 1 = wird zuerst überprüft, 2 = wird überprüft nachdem alle mit 1 markierten Dateisysteme überprüft wurden.

	Wenn man mehrere Datenträger verwendet, und diese alle ~~Überprüfen~~ lassen möchte, kann man bei all diesen Datenträgern Pass auf 1 stellen. Diese Datenträger werden dann parallel überprüft. Dies spart einiges an Zeit. Die häufig anzutreffende Empfehlung „Systempartition auf 1, alles andere auf 2“ stammt noch aus der Zeit, als nach einem fsck der Systempartition ein Reboot nötig war, und gilt inzwischen als überholt.		Wenn man mehrere Datenträger verwendet, und diese alle überprüfen lassen möchte, kann man bei all diesen Datenträgern Pass auf 1 stellen. Diese Datenträger werden dann parallel überprüft. Dies spart einiges an Zeit. Die häufig anzutreffende Empfehlung „Systempartition auf 1, alles andere auf 2“ stammt noch aus der Zeit, als nach einem fsck der Systempartition ein Reboot nötig war, und gilt inzwischen als überholt.

	Wenn mehrere Dateisysteme auf demselben Datenträger mit 1 markiert wurden, werden diese nacheinander geordnet nach ihrer Position auf dem Datenträger abgearbeitet. Hier empfiehlt sich rein aus logischen Gründen, z.B zuerst das root-Dateisystem ({{ic\|/}}) überprüfen zu lassen, und dann das home-Dateisystem, um sicher zu sein, dass {{ic\|/home}} nur dann überprüft wird, wenn {{ic\|/}} in Ordnung ist.		Wenn mehrere Dateisysteme auf demselben Datenträger mit 1 markiert wurden, werden diese nacheinander geordnet nach ihrer Position auf dem Datenträger abgearbeitet. Hier empfiehlt sich rein aus logischen Gründen, z.B zuerst das root-Dateisystem ({{ic\|/}}) überprüfen zu lassen, und dann das home-Dateisystem, um sicher zu sein, dass {{ic\|/home}} nur dann überprüft wird, wenn {{ic\|/}} in Ordnung ist.