Linux und Windows teilen sich problemlos eine Festplatte, doch der Zugriff auf die Partitionen des jeweils fremden Systems sorgt oft für Probleme – wir erklären, woran das liegt.

Dateisysteme organisieren Datenträger wie Festplatten(-partitionen), USB-Sticks, CDs und DVDs oder die aus der Mode gekommenen Disketten. Wenn Sie eine Partition formatieren, also mit einem Dateisystem versehen, dann schaffen Sie damit die nötigen Strukturen, um anschließend Verzeichnisse und Dateien auf dieses Medium zu kopieren. Damit Sie die Daten später auch wiederfinden, ist eine gewisse Organisation notwendig: Auf dem Datenträger muss z. B. vermerkt werden, welche Datenbereiche noch (für neue Dateien) verfügbar sind und wo sich die Datenblöcke, also die eigentlichen Inhalte, bereits vorhandener Dateien befinden.

Nehmen wir an, dass Sie einen USB-Stick mit einem eigenen, selbst ausgedachten Dateisystem versehen wollen. Dazu könnten Sie den Flash-Speicher, der für dieses Beispiel 1 GByte groß sein soll, in 1?024 x 1?024 Datenblöcke der Größe 1 KByte unterteilen. (1?024 x 1?024 x 1 KByte = 1 GByte.) Wenn Sie auf Unterverzeichnisse verzichten können, benötigt Ihr Dateisystem nur ein simples Inhaltsverzeichnis. Verlangen Sie außerdem, dass Dateien zusammenhängend gespeichert werden (sich die Daten also in aufeinanderfolgenden Datenblöcken befinden), dann können Sie für jede Datei in das zentrale Inhaltsverzeichnis den Dateinamen, die Blocknummer des ersten Blocks sowie die Anzahl der belegten Blöcke und die tatsächliche Dateigröße schreiben. Die Größe der Datei ergibt sich nicht automatisch aus der Blockanzahl, denn Dateien können ja im letzten Block nur einen Teil des verfügbaren Speichers nutzen: Im Beispiel mit Blockgröße 1 KByte braucht z. B. eine winzige Datei der Größe 100 Byte trotzdem einen kompletten Block, weil Sie mit dem Blocknummer-Schema Blöcke nur vollständig einer Datei zuordnen können. Damit könnte ein einfaches Inhaltsverzeichnis für den USB-Stick die Form von Tabelle 1 annehmen: Die ersten beiden Blöcke (Nummern 0 und 1) stehen für das Inhaltsverzeichnis zur Verfügung, los geht es dann mit Dateiinhalten in Block 2. (1 KByte sind 1?024 Byte, nicht 1?000.)

Auf Datenträgern wie CDs und DVDs, die nur einmal beschrieben werden, weil sie nach dem Brennen nicht mehr veränderbar sind, reicht ein einfaches Dateisystem wie das oben beschriebene im Prinzip aus – es fehlt nur noch die Möglichkeit, Unterordner anzulegen. Für Festplatten, USB-Sticks und Disketten ist dieser Ansatz aber nicht geeignet, denn dort ist es nötig, Dateien auch wieder löschen zu können: Dadurch werden ehemals belegte Datenblöcke wieder verfügbar, und beim späteren Anlegen neuer Dateien müssen diese Blöcke “recycelt”, also erneut genutzt werden. Hier stößt unser einfaches Dateisystem an seine Grenzen: Es kann passieren, dass Sie viele Bereiche mit freien (ehemals belegten) Datenblöcken haben, dass aber keiner davon groß genug ist, um eine größere Datei aufzunehmen, obwohl die Gesamtzahl der freien Datenblöcke dafür locker ausreichen würde. Dieser Effekt heißt Fragmentierung – um wieder Platz zu schaffen, müsste der Datenträger defragmentiert werden, wozu das System die meisten Dateien von hinteren Bereichen nach vorne verschieben müsste, um die entstandenen Lücken zu schließen: unpraktisch!

Komplexere Dateisysteme

Um veränderbare Datenträger sinnvoll nutzen zu können, haben Betriebssystem-Entwickler sich viele unterschiedliche Mechanismen und Verwaltungsstrukturen ausgedacht; so ist z. B. statt des Speicherns von Anfangsblock und Blockanzahl eine Liste aller verwendeten Blöcke üblich: Damit kann das System beliebige freie Blöcke auf dem Datenträger nutzen, wenn es eine neue Datei anlegen will. Das Verwalten solcher Blocklisten ist komplexer, und es gibt keine ideale Methode dafür.

Im Ergebnis sind etliche Dateisysteme entstanden, die zueinander nicht kompatibel sind. Stecken Sie z. B. einen mit dem Linux-Dateisystem Ext3 (Third Extended Filesystem) formatierten USB-Stick an einem Windows-PC ein, können Sie auf die gespeicherten Dateien nicht zugreifen: Windows erkennt das Ext3-Dateisystem nicht und weiß nicht, wie es die Dateien erreichen kann.

Linux ist hier “umgänglicher” und bringt Treiber für zahlreiche fremde Dateisysteme mit, z. B. solche von Windows und Apples OS X. Wenn Sie also umgekehrt z. B. einen mit NTFS (Windows) formatierten USB-Stick an einem Linux-PC einstöpseln, erkennt Linux das Dateisystem und erlaubt den Zugriff auf die Dateien – nur bedeutet das nicht zwingend, dass Sie als normaler Anwender auch direkt Zugriff erhalten; es kann passieren, dass nur der Administrator root die Dateien auf dem Stick sehen kann. Woran liegt das?

Metadaten

Neben den zwingend nötigen Informationen, die jedes Dateisystem für Dateien verwalten muss (im Wesentlichen: Wie heißt die Datei und welche Datenblöcke belegt sie?) speichern alle heute verwendeten Dateisysteme noch zusätzlich so genannte Metadaten – das sind Daten, welche die Datei über Name und Position hinaus beschreiben. Eine wichtige Komponente der Metadaten sind unter Linux der Dateibesitzer, die Besitzergruppe und die Zugriffsrechte (lesen, schreiben, ausführen; für Besitzer, Gruppenmitglieder und sonstige Anwender). Wenn Sie in der Shell ein Verzeichnis mit ls -l auflisten, sehen Sie diese Informationen (Abbildung 1). Am linken Rand stehen für jede Datei zehn Zeichen, von denen die letzten neun jeweils einer der Buchstaben r (read, lesen), w (write, schreiben) und x (execute, ausführen) oder ein Minuszeichen sind – wenn an einer Position ein Buchstabe steht, ist das jeweilige Recht gesetzt. Wenn nicht, fehlt das Recht. Die erste Dreiergruppe beschreibt dabei die Zugriffsrechte für den Dateibesitzer, die zweite Dreiergruppe die Rechte der Gruppenmitglieder und die letzte Gruppe die Rechte der sonstigen Anwender. Die Datei von-allen-lesbar.txt in der Abbildung hat z. B. die folgenden Rechte:

• Der Dateibesitzer (esser) darf die Datei lesen und schreiben (rw-),
• Mitglieder der Gruppe users (also alle normalen Benutzer, das Beispiel kommt von einem OpenSuse-System, das alle regulären Nutzer der Gruppe users zuordnet) dürfen nur lesen (r--),
• und die sonstigen Benutzer (also solche, die weder der Besitzer noch Mitglieder der Gruppe users sind) dürfen ebenfalls nur lesen (die letzte Dreiergruppe r--).

Ausführen darf niemand diese Beispieldatei, an den x-Positionen steht ja immer ein Minuszeichen.

Abbildung 1: Bei der Anzeige eines Verzeichnisses mit “ls -l” sehen Sie die Zugriffsrechte für Dateibesitzer, Gruppenmitglieder und andere Benutzer.

Die neun Zugriffsrechte sowie die Angaben zu Dateibesitzer und Besitzergruppe finden Sie bei allen Unix-artigen Systemen: Falls Sie z. B. einen Rechner mit FreeBSD verwenden, tauchen diese Angaben beim Einsatz von ls in gleicher Weise auf. Auch auf einem Mac, dessen OS X auf einer Unix-Variante basiert, finden sich diese Zugriffsrechte und Besitzer-/Gruppeninformationen. Windows hingegen ist nicht in der Tradition der Unix-Betriebssysteme entstanden, sondern war eine Weiterentwicklung von MS-DOS. DOS kennt keine Dateibesitzer (weil es gar keine Benutzerverwaltung hat), und entsprechend gibt es im DOS-eigenen Dateisystem FAT (File Allocation Table) auch keine Möglichkeit, Hinweise zum Besitzer oder zu Zugriffsrechten zu speichern. Stattdessen kennt FAT nur die vier Datei-“Attribute” Read-only (nur lesbar), Archive (archiviert), Hidden (versteckt) und System (Systemdatei), die für jede Datei entweder gesetzt oder nicht gesetzt sind. Wenn eine FAT-Datei das Attribut Read-only hat, entspricht das in etwa einem fehlenden Schreibrecht – für alle Anwender.

NTFS und die ACLs

NTFS (New Technology Filesystem) ist das Dateisystem der moderneren Windows-Versionen (Windows NT, XP, Vista, 7, 8), und es wurde für den Einsatz in einem Multi-User-Betriebssystem konzipiert. Darum ist es bei NTFS möglich, mit jeder Datei Informationen über den Besitzer und über Zugriffsrechte zu speichern. Diese sehen aber völlig anders als bei Unix-Dateisystemen aus, denn Windows verwendet so genannte Access Control Lists (ACLs, dt.: Zugriffskontrolllisten), um zu speichern, wer wie auf die Datei zugreifen darf. Vereinfacht sind ACL-Einträge Aussagen der Form “Benutzer Müller darf diese Datei lesen”, und der Dateibesitzer kann unter Windows prinzipiell beliebig viele solcher Aussagen an eine Datei anhängen. Ein einzelner Eintrag der ACL heißt ACE (Access Control Entry, dt.: Zugriffskontrolleintrag).

ACLs gibt es übrigens auch unter Linux, als Erweiterung der “klassischen” Unix-Zugriffsrechte [1], sie werden aber meist nicht verwendet. Für den Einsatz eines Linux-Rechners im privaten Haushalt mit nur wenigen Anwendern reichen die klassischen Mechanismen der Rechtevergabe auch völlig aus, denn hier geht es im Wesentlichen darum, Anwendern den Zugriff auf Dateien anderer Benutzer zu verbieten, so dass jeder die Inhalte seines Home-Verzeichnisses schützen kann.

Die spannende Frage ist nun, was passiert, wenn Sie unter Linux auf eine NTFS-Partition oder einen mit NTFS formatierten USB-Stick zugreifen. Prinzipiell wäre es für den NTFS-Treiber unter Linux kein Problem, die in den Metadaten gespeicherten ACLs auszulesen – aber wie sollen diese interpretiert werden, wenn unter Windows und Linux ganz unterschiedliche Benutzerlisten und Gruppen gepflegt werden?

Es gibt auf beiden Betriebssystemen einen privilegierten Benutzer; bei Windows heißt er Administrator, bei Linux root. Die Rollen sind nicht exakt gleich, aber es wäre z. B. naheliegend, Dateien, die auf einem NTFS-Dateisystem dem Administrator gehören, unter Linux dem root-Account zuzuordnen. Nun könnten Sie noch unter beiden Betriebssystemen die gleichen Benutzerkonten anlegen – etwa mueller, maier und schmidt. Ob damit eine Zuordnung funktionieren kann?

User-IDs und Security-IDs

Sowohl NTFS als auch die Linux-Dateisysteme wie Ext3 speichern bei den Besitzerinformationen keine Benutzernamen, sondern numerische IDs. Bei Linux ist das eine einfache Zahl: root hat die User-ID 0, der erste normale Anwender erhält meist die User-ID 1000, für weitere Benutzer wird ab 1000 hochgezählt. Wenn der Benutzer mueller der erste im System war und die User-ID 1000 erhalten hat, steht darum in den Metadaten aller vom ihm erzeugten Dateien im Besitzerfeld die Nummer 1000. Dadurch ist es u. a. leicht, einen Benutzer umzubenennen.

Auch NTFS speichert mit jeder Datei den Dateibesitzer – allerdings über einen ACE. Die verwendete Aussage ist dabei in der Form “mueller besitzt diese Datei”. Auch hier landet nicht der Benutzername im ACE, sondern eine ID. Die heißt bei Windows nicht User-ID, sondern Security ID (SID, dt.: Sicherheits-ID) und kann nicht nur für einen Benutzer, sondern auch eine Benutzergruppe stehen. SIDs sind keine einfachen Zahlen, sondern komplexe Kombinationen der Form S-1-5-21-2970240520-814345752-3821568977-500, wobei der letzte Teil (hier 500) eine lokale User-ID ist. Der Administrator hat bei Windows die User-ID 500, die normalen Anwender fangen (wie bei Linux) mit Nummer 1000 an. Windows-Anwender können mit dem Kommando wmic useraccount get name,sid in einem Terminalfenster herausfinden, welche SIDs das System verwendet (Abbildung 2).

Abbildung 2: Das Windows-Tool “wmic” gibt Auskunft über die SIDs der eingerichteten Benutzer.

Wenn Linux nun die ACL einer NTFS-Datei ausliest, stößt es auf diese SIDs. Mit den Werten kann es aber nichts anfangen: Es kann nicht erkennen, wer unter Windows der zugehörige Benutzer ist – und erst recht kann es daraus nicht ableiten, wie ein ACE unter Linux zu interpretieren wäre.

Technisch gibt es keine allgemeine Lösung für dieses Dilemma, und so bindet Linux fremde Dateisysteme nach einem Schema ein, das die konkreten Zugriffsrechte weitgehend ignoriert: Aus Linux-Sicht gehören dann alle Dateien und Ordner einem einzigen Benutzer (standardmäßig root) und zu einer einzigen Gruppe (ebenfalls root), und auch die Zugriffsrechte sind einheitlich – unabhängig von den unter Windows festgelegten Einstellungen. Normale Anwender haben dann keinen Zugriff auf die Windows-Dateien.

Von Linux zu Linux

Das Problem mit den Zugriffsrechten gibt es übrigens auch beim parallelen Einsatz mehrerer Linux-Versionen, wenn Sie dort die Benutzerkonten nicht synchron halten – mit “synchron” ist dabei gemeint, dass Benutzer und Gruppen auf allen Linux-Installationen dieselben User- und Gruppen-IDs verwenden und die Benutzer jeweils Mitglieder derselben Gruppen sind.

Haben Sie auf einem Rechner mehrere Linux-Distributionen installiert und eine gemeinsame Partition für die Home-Verzeichnisse eingerichtet, die Sie aus allen Distributionen heraus nach /home mounten, dann funktioniert das nur, wenn die User- und Gruppen-IDs einheitlich sind.

Praxis: NTFS und FAT

Die Linux-Distributionen binden NTFS- und FAT-Datenträger mit unterschiedlichen Mount-Optionen ein. Das führt, wie oben beschrieben, in einigen Fällen dazu, dass für den Zugriff auf die Dateien und Verzeichnisse Root-Rechte nötig sind. Indem Sie die Mount-Optionen selbst festlegen, können Sie dafür sorgen, dass Sie auch als normaler Anwender vollen Lese- und Schreibzugriff haben. Das geht wahlweise beim manuellen Mounten mit mount (was vor allem für externe Platten und USB-Sticks sinnvoll ist) und beim automatischen Mounten über einen Eintrag in der Konfigurationsdatei /etc/fstab.

In beiden Fällen müssen Sie sich zunächst einige Informationen verschaffen:

• Über welche Gerätedatei können Sie den Datenträger ansprechen? Mit fdisk -l erhalten Sie eine Liste der Partitionen aller Festplatten. Aus dieser erkennen Sie die Gerätedatei der Partition, die Sie mounten möchten (z. B. /dev/sdb4). Wenn Sie eine Platte mit GPT-Partitionstabelle anschließen, kann fdisk die Partitionen nicht anzeigen; dann hilft das Tool gdisk weiter, das beim Aufruf aber die Gerätedatei der Platte benötigt, z. B. gdisk -l /dev/sdb. (Ganz aktuelle fdisk-Versionen kommen auch mit GPT-Tabellen zurecht, z. B. die fdisk-Version von OpenSuse 13.1.) Ist gdisk nicht installiert, bleibt noch die Ausgabe der vom Linux-Kernel dynamisch erzeugten Datei /proc/partitions (mit cat /proc/partitions) – dort fehlen allerdings Informationen über die Partitionstypen.
• In welches Verzeichnis wollen Sie den Datenträger mounten? Hier bietet sich ein Unterordner von /mnt an, z. B. /mnt/windows. Prinzipiell ist aber jedes beliebige, leere Verzeichnis als Mount Point geeignet.
• Handelt es sich um eine FAT- oder NTFS-Partition? Für FAT ist der Linux-Dateisystemname vfat, bei NTFS ntfs-3g. (Wenn Sie den kommerziellen NTFS-Treiber von Paragon [2] verwenden, ist ufsd die richtige Bezeichnung.)
• Welche User-ID und Gruppen-ID hat der Benutzer (meist: Sie selbst), dem Sie vollen Zugriff auf den Datenträger erlauben wollen? Wenn Sie mit dem richtigen Benutzerkonto angemeldet sind, können Sie in einer Shell id eingeben, um die Werte herauszufinden (Abbildung 3). Gleich am Anfang der Ausgabe finden Sie hinter uid= und gid= die numerischen Benutzer- und Gruppen-IDs; in Klammern steht jeweils der Klartextname. Der Rest der Zeile enthält Informationen über weitere Gruppen, in denen Sie Mitglied sind – den Teil können Sie ignorieren. Bei OpenSuse erhält der erste reguläre Benutzer die UID 1000 und GID 100, während es unter Kubuntu in beiden Fällen die Zahl 1000 ist. Das liegt an einem unterschiedlichen Ansatz bei der Verwaltung von Standardgruppen (siehe Kasten Standardgruppen).

Abbildung 3: Merken Sie sich aus der Ausgabe von “id” die Werte, die hinter “uid=” und “gid=” stehen.

Standardgruppen

Linux und andere Unix-Systeme ordnen jedem Anwender stets eine Standardgruppe zu. Wenn der Anwender eine neue Datei erzeugt, wird seine Standardgruppe als “Besitzergruppe” in den Metadaten der Datei eingetragen. Durch die Mitgliedschaft in weiteren Gruppen kann ein Anwender diesen Eintrag anpassen. Ein klassisches Szenario ist die Projektgruppe: Wenn z. B. die Benutzer maier, mueller und schmidt Mitglieder der Gruppe projekt1 sind, dann kann der Benutzer maier Dateien erzeugen, die als Besitzergruppe nicht seine Standardgruppe, sondern die Gruppe projekt1 haben. Vergibt er dann Lese- und Schreibrechte für die Gruppe, können auch mueller und schmidt die Datei lesen und verändern, aber niemand anders (sofern die Zugriffsrechte für die sonstigen Benutzer das verhindern).

Unabhängig von diesen bewussten Rechtevergaben bei Projektarbeiten muss aber jede Datei einen Besitzergruppeneintrag haben – eben dafür gibt es die Standardgruppe. In der systemweiten Benutzerdatei /etc/passwd trägt das System für jeden Benutzer seine Standardgruppe ein (Abbildung 4).

Abbildung 4: In der Datei “/etc/passwd” finden Sie zu jedem Benutzernamen zwei IDs (hier lila hervorgehoben): erst die User-ID, dann die ID der Standardgruppe.

Die Frage ist nun, welche Standardgruppe zu verwenden ist. Hier gibt es zwei Ansätze:

• Einige Linux-Distributionen, darunter OpenSuse, verwenden einheitlich für alle Benutzer die Standardgruppe users (meist mit der Gruppen-ID 100). Erzeugen Benutzer auf solchen Linux-Systemen neue Dateien, sind die Gruppen-Zugriffsrechte entsprechend konservativ gesetzt (nur lesen, nicht schreiben), denn andernfalls könnte ja jeder andere Benutzer die Dateien einfach verändern.
• Der Alternativansatz heißt “User Private Groups” (UPG). Hier erstellt das System für jeden Benutzer eine gleichnamige Gruppe und verwendet sie als Standardgruppe dieses Benutzers. Im Normalfall sind dabei die User-ID und die Gruppen-ID der namensgleichen Standardgruppe identisch, das ist aber nicht zwingend so. Diese Standardgruppen enthalten zunächst nur den einen Benutzer; sie könnten aber theoretisch um weitere Benutzer erweitert werden [3]. Neue Dateien eines Benutzers haben hier automatisch Lese- und Schreibrechte für Gruppenmitglieder. Das ist nicht weniger sicher als das obige Modell, weil ja nur der eine Anwender Mitglied seiner Standardgruppe ist.

Dass im einen Fall automatisch Gruppenschreibrechte vergeben werden und im anderen nicht, liegt an einer Einstellung namens “user file creation mask” (umask). Anwender können festlegen, welche Zugriffsrechte das System beim Erzeugen einer neuen Datei nicht vergeben soll. Unter OpenSuse hat die umask den Wert 022. Die Ziffer in der Mitte beschreibt die nicht gewollten Gruppenrechte, und 2 steht für das Schreibrecht. Neue Dateien sind also nicht durch Gruppenmitglieder schreibbar. Anders bei Kubuntu: Hier hat die umask den Wert 002, und das Schreibrecht für Gruppenmitglieder bleibt erhalten [4].

Aus den Daten können Sie sich nun ein Mount-Kommando zusammensetzen. Im Folgenden gehen wir davon aus, dass Sie mit diesen Parametern arbeiten:

• Gerätedatei: /dev/sdb1
• Mount Point: /mnt/windows
• Dateisystem: NTFS (ntfs-3g)
• Benutzer und Gruppe: uid=1000, gid=1000 (Kubuntu)

Für das manuelle Mounten ergibt sich dieses Kommando:

sudo mount -t ntfs-3g -o umask=077,fmask=177,uid=1000,gid=1000 /dev/sdb1 /mnt/windows

Danach können Sie auch ohne Root-Rechte auf die Dateien und Verzeichnisse auf der Windows-Partition zugreifen (Abbildung 5): Alle Dateien “gehören” Ihnen, und Sie haben Lese- und Schreibrechte für alle Dateien sowie das Recht, in alle Verzeichnisse hineinzuwechseln. Die Optionen umask=077 und fmask=177 sorgen dafür, dass nur der ausgewählte Benutzer Zugriff erhält – alle sonstigen regulären Anwender können nicht auf die NTFS-Partition zugreifen.

Abbildung 5: Nach dem Mounten der NTFS-Partition mit speziellen Parametern klappt der Zugriff problemlos.

Wollen Sie die NTFS-Partition schon beim Booten automatisch einbinden lassen, erzeugen Sie einen Eintrag in der Konfigurationsdatei /etc/fstab (filesystem table, Dateisystemtabelle). Sie benötigen Root-Rechte, um diese Datei zu bearbeiten.

Fügen Sie hier eine Zeile der folgenden Form ein:

/dev/sdb1 /mnt/windows  ntfs-3g  umask=077,fmask=177,uid=1000,gid=1000  0  0

Sie erkennen die meisten Komponenten aus dem mount-Aufruf wieder; sie stehen hier nur leicht verändert und in anderer Reihenfolge.

Einen Praxisartikel, der den Parallelbetrieb von Windows und zwei Linux-Distributionen (inklusive Zugriff auf die NTFS-Partition von Linux aus) beschreibt, finden Sie in unserem Archiv [5].

NTFS-Mount-Probleme

Im Idealfall kann der KDE-Dateimanager Dolphin NTFS-Datenträger per Mausklick einbinden – bei USB-Sticks sollte das auf Anhieb klappen, während bei eingebauten Festplatten das Root-Passwort (OpenSuse) bzw. das Benutzerpasswort benötigt wird (Abbildung 6). Danach wird die Partition mit geeigneten Parametern (ähnlich wie gerade für das manuelle Mounten beschrieben) eingebunden, und Sie können Daten darauf lesen und schreiben (Abbildung 7).

Abbildung 6: Wenn Sie über KDEs Dolphin einen NTFS-Datenträger einbinden, müssen Sie das Root-Passwort (oder bei Kubuntu Ihr eigenes Passwort) eingeben.

Abbildung 7: USB-Sticks können Sie unter Linux auch dann problemlos einbinden, wenn sie NTFS-formatiert sind.

Manchmal klappt das aber nicht, denn beim Parallelbetrieb mit Windows 8 gibt es mit dem “Schnellstart” (Fast Startup) eine neue Fehlerquelle: Windows hinterlässt beim Herunterfahren die NTFS-Partition in einem unsauberen Zustand, und beim Versuch, diese unter Linux über den KDE-Dateimanager einzubinden, erscheint die Fehlermeldung aus Abbildung 8.

Abbildung 8: Diese Fehlermeldung weist darauf hin, dass die Windows-Partition beim Herunterfahren nicht sauber ausgehängt wurde; darum können Sie sie nicht unter Linux mounten.

Sie lösen dieses Problem, indem Sie unter Windows den Schnellstart deaktivieren. Das geht folgendermaßen:

1. Drücken Sie [Windows]+[R], geben Sie im Schnellstartfenster den Befehl control ein, und schicken Sie das Kommando mit [Eingabe] ab, um die Systemsteuerung zu öffnen.
2. Klicken Sie auf den Eintrag Hardware und Sound und dann im Bereich Energieoptionen auf Netzschalterverhalten ändern.
3. Im unteren Bereich des erscheinenden Dialogs (Abbildung 9) gibt es eine Option Schnellstart aktivieren (empfohlen), die aktiviert ist – entfernen Sie das Häkchen vor dieser Option. Falls das nicht möglich ist, sehen Sie oben den Hinweis Einige Einstellungen sind momentan nicht verfügbar. Klicken Sie diesen an (er sollte dadurch verschwinden) und versuchen Sie dann erneut, das Häkchen zu entfernen.

4. Abschließend klicken Sie auf Änderungen speichern; danach können Sie die Systemsteuerung mit [Alt]+[F4] verlassen.

   

   Abbildung 9: Wenn Sie unter Windows 8 den Schnellstart deaktivieren, beschwert sich Linux nicht mehr über das unsauber ausgehängte Windows-Dateisystem.

Wenn Sie auf den Schnellstart nicht verzichten wollen, können Sie alternativ den Datenträger im Nur-Lese-Modus einbinden: Das funktioniert auch dann, wenn Windows ihn beim Runterfahren nicht sauber ausgehängt hat. Allerdings gelingt das nur auf der Kommandozeile. Sie müssen einen mount-Befehl (wie oben beschrieben) zusammenbauen und bei den Mount-Optionen noch ro (read-only) ergänzen, also statt -o umask=077,fmask=177,uid=1000,gid=1000 die Optionen -o ro,umask=077,fmask=177,uid=1000,gid=1000 verwenden.

Fazit

Wenn Sie eine NTFS-Partition parallel unter Windows und Linux nutzen wollen, müssen Sie beim Einbinden dafür sorgen, dass die Dateien mit passenden User- und Gruppen-IDs verfügbar gemacht werden – die Linux-Distributionen tun das nicht automatisch. Verwenden mehrere Anwender den PC, wird die Situation noch komplexer, weil Linux die unter Windows eingestellten Dateibesitzer und Zugriffsrechte nicht sinnvoll interpretieren kann. Problemlos ist dagegen der Zugriff auf FAT- oder NTFS-formatierte USB-Sticks, die Sie in Dolphin per Mausklick mounten können. Der Kasten Experimente gibt eine Anregung für eigene Experimente mit Dateisystemen. Wenn Sie mehr über den Aufbau von Dateisystemen erfahren möchten, empfiehlt sich der Blick in ein Betriebssysteme-Lehrbuch, wie z. B. den Klassiker von Tanenbaum [6]. (hge)

Experimente

Wollen Sie die Struktur eines Dateisystems selbst untersuchen, erzeugen Sie für erste Tests ein leeres Disketten-großes Image, das Sie dann mit verschiedenen Tools formatieren und analysieren können. Klassische 3,5-Zoll-Disketten sind 1?440 KByte groß. Sie können das Kommandozeilentool dd verwenden, um eine leere Datei in dieser Größe zu erzeugen:

dd if=/dev/zero of=test.img bs=1k count=1440

Die Parameter legen fest, dass dd aus der Spezialdatei /dev/zero liest (welche beim Lesezugriff beliebig viele Nullen zurückgibt), in die für die Tests vorgesehene Ausgabedatei (hier test.img) schreibt und dabei 1?440 Blöcke (count) der Blockgröße 1 KByte (bs, block size) erzeugt. Die so erstellte Datei hat dann genau Diskettengröße und als Inhalt nur Bytes mit dem ASCII-Wert 0.

Die leere Image-Datei formatieren Sie jetzt als FAT-Datenträger und erzeugen dann einen Hexdump:

/sbin/mkfs.msdos test.img
hexdump -C test.img > test.dump1

Dann legen Sie in Ihrem Home-Verzeichnis einen Unterordner mnt an und mounten das frisch formatierte Image in diesen Ordner:

mkdir -p ~/mnt
sudo mount -o loop,uid=1000 -t msdos test.img ~/mnt/

Beim Mounten von FAT-Images können Sie zwischen zwei Varianten des FAT-Treibers wählen: Hier wählen Sie mit -t msdos die simplere Variante, die nur klassische DOS-Dateinamen (maximal acht Buchstaben, dann ein Punkt, dann maximal drei Buchstaben für die Dateiendung) unterstützt. Normal verwendet man stattdessen -t vfat, um die mit Windows 95 eingeführten Erweiterungen für lange Dateinamen zu unterstützen. Die Option -o loop ist notwendig, weil Sie keine echte Diskette mounten, sondern eine Image-Datei.

Erzeugen Sie dann eine kleine Testdatei im Image, hängen Sie es wieder aus und erstellen Sie einen zweiten Hexdump der nun geänderten Image-Datei:

echo "Kleiner Test" > ~/mnt/test.txt
sudo umount ~/mnt/
hexdump -C test.img > test.dump2

Mit einem Dateivergleicher wie tkdiff oder kdiff3 (beide müssten Sie zunächst nachinstallieren) können Sie nun komfortabel die Hexdumps der beiden Image-Versionen vergleichen, z. B. mit

kdiff3 test.dump*

und erhalten dann die Darstellung aus Abbildung 10. In der rechten Hälfte können Sie gut erkennen, dass hier beim Schreiben der Datei test.txt zwei neue Bereiche entstanden sind: Einer enthält den Dateinamen und die Metadaten für die Datei TEST.TXT, der zweite Bereich enthält den eigentlichen Dateiinhalt (“Kleiner Test”).

Abbildung 10: Der Aufbau eines FAT-Dateisystems ist relativ übersichtlich. Sie können an den Änderungen im Hexdump erahnen, wo welche Informationen abgelegt werden.