duddits
Goto Top

LAN-Server (NFS und Samba) Grundlagen

Hi,

und Willkommen zum Tutorial LAN-Server(NFS und Samba) Grundlagen. Ich schreibe dieses
Tutorial, um zu zeigen wie einfach es sein kann sich selbst einen NFS oder Samba
einzurichten.
Dieses Tutorial beschreibt in erster Linie die Konfiguration von
Netzwerkdiensten, die innerhalb von lokalen Netzwerken zur Verfügung gestellt werden.
Es richtet sich in erster Linie an die Distributionen Suse Linux, Fedora Core sowie Red Hat.
Trotz allem sollte dies auch auf andere Distributionen übertragbar sein.
Ich habe das Tutorial in drei Abschnitte geteilt.

Teil 1: NFS
Teil 2: Samba
Teil 3: Infos

Um alles was zu vereinfachen wird immer davon ausgegangen, das der Server unter den Namen server
erreichbar ist und sich in der Domain domaine befindet. Alle Rechner haben die Netz-ID 192.168.1
und befinden sich auch in der Domian domaine. Der Client ist immer der Rechner bill mit der IP
192.168.1.100. Die Server IP ist 192.168.1.1.

Teil 1

NFS-Server (Linux Verzeichnisse)

NFS steht für Network File System und ermöglicht es, dass ein Rechner seine lokalen Verzeichniss einem anderen Rechner via Netzwerk zur Verfügung stellen kann.

Bevor man den NFS-Server einrichten kann muss man die entsprechenden Packete installieren. Diese heißen üblicherweise nfs-util und portmap. Die Konfiguration erfolgt durch drei Dateien:
/etc/exports, /etc/hosts.allow und /etc/hosts.deny.

Die zentrale Konfiguration für NFS ist /etc/exports. Diese Datei steuert, welcher Rechner auf
welche Verzeichnisse zugreifen darf ( read-only oder read-write).
Die Rechner können durch entweder durch Namen oder IP-Adresse angegeben werden. Weiterhindarf auch das Jokerzeichen * verwendet werden ( z.B *.domaine).

Das folgende Beispiel veranschaulicht die Verwendung von /etc/exports
# /etc/exports
# rw = read write, rw = read only
# sync = Synchron, async = Asynchron
/public		192.168.1.*(ro,async)	*.domaine(ro,async)
/home/bill	bill.domaine(rw,async)
Dieses kleine Beispiel gibt an, dass alle Clients Lesezugriffe auf /public haben wenn sie mit dem
Namen *.domaine oder der IP-Adresse 192.168.1.* zugreifen.
Darüber hinaus hat der Rechner bill.domaine Lese- und Schreibzugriffe auf /home/bill aber nur
Leserzugriffe auf /public.
sync gibt an, dass der NFS-Server erst nach Änderungen an einer Datei die Bestätigung sendet,
wenn diese tatsächlich gespeichert wird. Per default gilt sync. Der Vorteil an async ist, dass
es bis zu 10 mal schneller ist als sync, aber weniger sicher.

Falls der NFS-Server bereits am laufen ist, werden die Änderungen in /etc/exports erst durch
folgenden Befehl wirksam: exportfs -a

Achtung:

IP-Adressen in /etc/exports habe nur dann Gültigkeit, wenn die dazu gehörigen Rechernamen nicht bekannt sind (entweder durch einen Nameserver oder /etc/hosts).

Zugriffe:

Diese werden durch die Dateien /etc/hosts.allow und /etc/hosts.deny gesteuert. Diese Dateien
geben an welcher Rechner überhaupt auf den NFS-Server zugreifen dürfen. In der Hirachie des
Zugriffschutzes stehen diese beiden Dateien an erster Stelle.
Wobei /etc/hosts.allow zuerst ausgewertet wird. Wird einem dort nicht expliziet erlaubt auf den Dienst zuzugreifen, so wird /etc/hosts.deny ausgewertet. Wenn dort auch einem nicht der Zugriff explizit verweigert wird, so wird der Zugang gewährt.
Das heißt wenn einem Rechner in /etc/exports der Zugriff gewährt wird kann ihm
dieser dennoch in /etc/hosts.deny verwährt sein. Somit hat er keinen Zugriff auf den NFS-Server.
/etc/exports ist nur für die Rechner relevant die diesen überhaupt kontaktieren können.
Ein Beispiel:

# /etc/hosts.allow
# bestimmte Dienste erlauben
ALL	:	localhost				: ALLOW
portmap	:	192.168.1.0/255.255.255.0 *.domaine	: ALLOW


# /etc/hosts.deny
ALL	:	ALL	: spawn (echo Attempt form %h %a to %d at $(date) \
				>> /var/log/deny.log)
Erklärung:
Vom lokalen Rechner werden alle Zugriffe auf alle Dienste erlaubt. Weiterhin werden alle Zugriffe auf den NFS-Server(portmap) aus dem lokalen Netz 192.168.1.* und der alle Rechner aus der Domain *.domaine.
Alle anderen werden in /etc/host.deny verweigert und gleichzeitig wird der Versuch durch die
spawn Anweisung Protokolliert.

Jeder Eintrag besteht aus drei Teilen, die durch Doppelpunkte getrennt sind. Der erste Teil gibt
den Dienst an, der zweite die IP-Adresse bzw. den Netzwerknamen und der dritte Teil gibt die
resultierende Aktionen (weitere Infos mit man 5 hosts_access).

Hinweis:
Diese Dateien werden nur dann ausgewertet, wenn auch der Dienst xinetd(früher inetd) läuft.
Man kann dies zum Beispiel feststellen in dem man dmesg | grep inetd oder xinetd eingibt.
Alternativ geht auch /etc/init.d/xinetd status. Läuft xinetd nicht so sollte er aktiviert werden
mit /etc/init.d/xinetd start.

Start:
Zum manuellen start müssen folgende Dienste gestartet werden:
/etc/init.d/portmap start
/etc/init.d/nfslock start
/etc/init.d/nfs start # unter SuSE nfsserver

  1. unter SuSE muss nfs durch nfsserver ersetzt werden

Automatischer Start:
chkconfig portmap 35 nfslock 35 nfs 35

oder

chkconfig --add portmap
chkconfig --level 35 portmap on
chkconfig --add nfslock
chkconfig --level 35 nfslock on
chkconfig --add nfs
chkconfig --level 35 nfs on

NFS-Status:

Anzeigen der Dämonen für den Betrieb des Rechners als NFS-Server:
rpcinfo -p

Client Zugriffe auf den NFS-Server anzeigen:
showmount -a


NFS-Client (Zugriff auf Linux-Netzwerkverzeichnisse)

Um einen Zugriff auf ein NFS-Verzeichniss zu haben verwendet man folgenden Befehl:
mount -t nfs server:/public /nfsdata

Damit wird das Verzeichis /public des Rechners server auf den lokalen Rechern unter dem
Verzeichnis /nfsdata verfügbar.(/nfsdata muss vor dem mount Befehl natürlich vorhanden sein!). Statt des Rechner Namens kann man auch die IP des NFS-Servers angeben.

Um NFS-Verzeichnisse schon während des Start Vorgangs zu mounten ist eine Ergänzung
in /etc/fstab erforderlich:

  1. /etc/fstab
server:/public /nfsdata nfs user,exec,bg 0 0

Damit wird das Verzeichis /public des Rechners server auf den lokalen Rechern unter dem
Verzeichnis /nfsdata verfügbar. Aber durch die NFS-spezifische Option bg wird der mount
Vorgang im Hintergrund ausgeführt, dies ist praktisch wenn das Netzwerkverzeichniss nicht sofort zur Verfügung steht.


Teil 2

Samba

Samba ist eine Programmsammlung, welches bei der Integration von Windows- und
Unix-/Linux-Rechnern hilft.
Der Name Samba wurde vom Protokoll SMB abgeleitet, welches wiederum für Server Message Block steht.
Dieser Teil zeigt lediglich nur die Grundlagen von Samba, für fortgeschrittene Funktionen
wie eine Authentifizierung via LDAP etc. ist folgende Website zu empfehlen:
http://www.samba.org/

Konfiguration:
Als zentrale Konfigurationsdatei dient /etc/samba/smb.conf.Eine einfache Freigabe könnte
folgendermassen aussehen:
; /etc/samba/smb.conf
[global]
	workgroup = Arbeitsgruppe
	security  = share

[public]
	path = /public
	guest ok = yes
	guest only = yes
Erklärung:
Damit wird der Arbeitsgruppe "Arbeitsgruppe" das Verzeichnis public angeboten. Dazu muss
natürlich das Verzeichnis /public erhalten sein. Der Zugriff ist ohne Passwort möglich, das liegt
daran, dass das Sicherheitslevel dort so gesetzt wurde (security = share) und das Gast Zugriffe
erlaubt werden (guest ok = yes; guest only = yes erlaubt nur Gastzugriffe). Dabei dürfen keine Dateien verändert werden (per default immer read only = yes).

Start:
Die Samba-Server funktionen werden von den Dämone nmbd und smbd zur
Verfügung gestellt.

nmbd --> dient zur internen Verwaltung und als Nameserver. Weiterhin stellt er
die Browsing-Funktioen bereit. Kann sogar als WINS-Server fungieren.

smbd --> stellt die Schnittstelle für die Clients dar und stellt diesen den Zugang zu
Verzeichnissen, Druckern und zur aktuellen Browsing-Liste zur Verfügung.

manueller Start:

/etc/init.d/smb start # Bei Red Hat/Feora Core reicht dieses Init-V-Script
/etc/init.d/nmb start # SUSE benötigt das auch noch

automatischer Start:

entweder:
chkconfig --add smb
chkconfig --level 35 smb on

oder
chkconfig smb 35 nmb 35

Test:
Zum Testen ob auch alles so funktioniert wie man es möchte, connectet man selbst vom Server auf den Server. Bei der Minimalkonfiguration oben ist kein Passwort erforderlich, somit gibt man einfach Return(auf die Taste Return klicken) ein.
smbclient -L loccalhost

Wenn man nun größere Änderungen an smb.conf vorgenommen hat sollte man die Datei erstmal nach Snytaktischen Fehlern überprüfen. Hierzu dient der Befehl testparm.
server:~/bin # testparm
Load smb config files from /etc/samba/smb.conf
Processing section "[public]"  
Processing section "[printers]"  
Loaded services file OK.
Server role: ROLE_STANDALONE
Press enter to see a dump of your service definitions

# Global parameters
[global]
	workgroup = Arbeitsgruppe
	...
Tipp:
Ab Samba 3.0 ist es möglich mit dem Schalter v (testparm -v) sich die Defaulteinstellungen von
smb.conf-optionen geben zu lassen.

Status:
Mit smbstatus kann man den aktuellen Status von Samba feststellen, zusätzlich aller aktiven
Verbindungen.

Protokollierung:
Samba protokolliert Status- und Fehlermeldungen üblicherweise in die Dateien
/var/log/samba/log.smbd und log.nmbd.

Sicherheitsstufen:
Samba kennt 5 verscheidene Sicherheitsstufen, diese werden in der smb.conf mit security
angegeben.

security = share: Samba arbeitet unter mit Share-Level-Sicherheit. Mit dieser Einstellung
verlangt Samba beim Verbindungsaufbau vorerst kein Passwort und Login-Namen.
Erst beim Zugriff auf Verzeichnisse oder Drucker ist eine Identifizierung
erforderlich.

security = user: Bei dieser Einstellung müssen sich die Clients mit Name und Passwort
anmelden, erst dann stehen die Freigaben zur Verfügung.

security = server: Samba delegiert die Authentifizierung an einen anderen Rechner (dieser
wird mit password server = name bestimmt).

security = domain: Wie security = server, allerdings muss es sich beim externen Rechner um
einen PDC handeln. Dabei muss der Samba-Server Teil der Domäne sein.

security = ads: Wie security = server es muss sich beim externen Rechner nur um einen
Active-Directory-Server handeln.

Benutzerverwaltung

Der Zugriff auf Verzeichnisse unter Samba erfolgt auf Basis der Linux-Benutzerverwaltung, wenn man die Authentifizierung nicht auf einen anderen Rechner delegiert hat. So werden der
Windows-Login-Name einem Linux-Login-Name zugeordnet.

Ein kleine Beispiel veranschaulicht mal Zuordnung:
Diese Beispiel gibt das Verzeichniss /public/bill frei unter dem Namen bill-data für den
Benutzer Bill.
[global]
	workgroup = Arbeitsgruppe
	security = user
	encrypt passwords = yes
[bill-data]
	path = /public/bill
	username = bill
	writeable = true
bill muss ein gültiger Benutzer auf dem Linux-System sein. ( dabei ist auf Gruß/Klein Schreibung
zu achten!). Wichtig ist, dass das Verzeichniss /public/bill existiert und dieser der Besitzer
des Verzeichnisses ist bzw. er die Rechte hat Daten bearbeiten zu können).
Durch username = bill gelten für den Benutzer bill, der von irgendeinen Windows-Client aus
auf test zugreift, alle Unix-Regeln der Zugriffsverwaltung.
Die Option encrypt passwords = yes bewirkt, dass Passwörter verschlüsselt werden, dies gilt ab Samba 3.0 per Default. Bei Windows-Clients die älter als 98 sind z.B 95 muss diese Option
explizit auf no gestellt werden.


Um auch so lange Benutzernamen wie unter Windows zu ermöglichen, gibt es die Möglichkeit eine Zuordnung zwischen den Benutzernamen von Windows und Linux zu erstellen, welches über eine Datei erfolgt.
Standartmässig gibt es schon eine Datei in /etc/samba mit dem Namen smbusers,
die diese Aufgabe übernimmt. Man kann aber auch eine neue Datei erstellen, welches dann diese Aufgabe übernimmt.
Der Name dieser Datei wird in smb.conf durch die Option username map angegeben:
  1. etc/samba/smb.conf
[global]
username map = /etc/samba/smbusers

Der Syntax der Datei ist ganz einfach. Est kommt der Linux-Name und dann das Zeichen =
gefolgt vom Windows-Namen.

  1. /etc/samba/smbusers
#root = administrator
bill = "Bill Newman"
#nobody = guest pcguest smbgues

Zum Schluss muss bill sich identifizieren, um auf /public/bill zugreifen zu können. Damit
bill sein Samba-Verzeichniss nutzen kann, muss man in /etc/samba/smbpasswd (üblicher Ort für die Passwort-Kontrolle von Samba) einen neuen Eintrag für bill vorsehen. Dabei hilft einem das Kommando smbpasswd.
server:~/bin #  smbpasswd -a bill
New SMB password:  *********
Retype New SMB password:  *********
Added user bill.
Password changed for user bill.

Verzeichnisse freigeben

Share-Level-Sicherheit

Zu beginn dieses Teiles wurde schon eine einfaches Beispiel für eine Share-Level-Sicherheit gegeben.
Dabei erfolgte der Zugriff ohne Login- und Passwort-Abfrage:

# /etc/samba/smb.conf (Share Level, Teil 1)
[global]
	workgroup = Arbeitsgruppe
	encrypt passwords = yes
	security  = share

[public]
	path = /public
	guest ok = yes
	guest only = yes
Durch die Optionen guest ok und guest only wird erreicht, dass jeder Zugriff auf das Verzeichnis
/public ohne Passwort erlaubt ist und dass der Zugriff immer dem Default-Account für guest
zugeordnet wird. Nomalerweise ist das der Benutzer nobody.
Welches das Default-Account für guest ist lässt sich mit folgenden Befehl feststellen:
server:~/bin # testparm -v -s | grep "guest account"
guest account = nobody

Man kann falls es notwendig ist mit guest account = username guest auch einen anderen Account
zuordnen.

Verzeichniss mit Passwort schützen

Das folgende ergänzende Beispiel zeigt ein Passwort geschütztes Verzeichnis. Dazu wird ein
Linux-Account angelegt(hier test), der mit smbpasswd ein Passwort zugewiesen bekommt.
Wenn nun ein Client auf das Verzeichniss zugreift, kann dieser einen beliebigen Benutzer angeben, aber das Passwort von test muss stimmen.
Dieses Passwort schützt nun den Zugang zum Verzeichnis protect.
Die Option browseable bewirkt, dass das Verzeichniss auf dem Client-Rechner sichtbar ist, noch bevor ein Zugang gewährt wird.
# /etc/samba/smb.conf (Share Level, Teil 2)
[pwprotection]
	path = /public/protect
	user = test
	writeable  = true
	browseable = true

User-Level-Sicherheit

Home-Verzeichnisse:
Die User-Level-Sicherheit entspricht eher dem Linunx-Sicherheitsmodell. Hier ein Beispiel
für eine User-Level-Sicherheit Freigabe:
# /etc/samba/smb.conf (Teil 1)
[global]
	workgroup = Arbeitsgruppe
	security = user
	username map = /etc/samba/smbusers
	encrypt passwords = yes
	map to guest = bad user
	guest account = nobody

[homes]
	writeable  = true
	browseable = false

Die beiden guest Einstellungen bewirken, dass alle Benutzer die in /etc/samba/smbusers keine Zuordnung finden dem Account nobody zugeordnet werden. Somit kann jeder auf dem Samba-Server kontakt aufnehmen.
Ein Zugriff auf Verzeichnisse ist aber nur dann möglich, wenn bei der Freigabe
auch guest ok = yes gegeben ist.
Man sollte wenn es geht die Option map to guest = bad user aus Gründen der Sicherheit auf map to guest = never stellen.
Die Gruppen [homes] hat hier eine Sonderrolle da sie bewirkt, dass das Home-Vezeichnis des gerade aktiven Benutzers unter dessen Name sichtbar wird.
Falls man möchte, dass die Benutzer nicht auf das Home-Verzeichnis, sondern auf ein anderes
Verzeichnis zugreifen sollen, kann man das mit dem Schlüsselwort path festlegen. Hier wird
stattdes in /etc/passwd eingestellten Verzeichnisses /private/samba/name verwendet:
path = path=/data/sambahome/%u
Eine Freigabe für alle würde so aussehen:
[forall]
	path = /public
	guest ok = yes
	read only = yes

Gruppenverzeichnisse

Das Home Verzeichiss ist immer nur für einen bestimmten Benutzer zugänglich. Es wäre aber manchmal auch sinnvoll einer ganzen Gruppe eine Freigabe zuzuordnen.
Dazu muss man zuerst den Linux-Account dieser Mitglieder einer Gruppe zuordnen. Anschließend kann man in smb.conf ein Verzeichniss definieren, welches alle Miglieder der Gruppe nutzen. Um sich etwas Schreibarbeit zu ersparen kann man auch mit @Name alle Mitglieder dieser Gruppe ansprechen.

# /etc/samba/smb.conf (Teil 2)
[gamersdata]
	path = /data/gamers
	writeable = true
	browseable = true
	user = @gamers
	create mask = 0770
	directory mask = 0770

Die zwei mask-Optionen stellt sicher, dass auch von Gruppenmitgliedern neu erstellte Dateien und Verzeichnisse von allen Gruppenmitgliedern bearbeitet werden können.

Client:

Um auf einen Samba-Server zu connecten gibt man einfach beim entsprechenden Dateimanger folgendes ein:
Konqueror: smb:/
Nautilus: smb:/

Über die Shell kommt das Kommando smbclient zur Hilfe.
Beispiel: smbclient -L server

Weiter Schalter sind:
W workgroupname
U benutzername

Sobald man zum externen Rechner eine Verbindung aufgebaut hat, kann man wie mit ftp sich mit ls Verzeichnisse ansehen, mit get Dateien auf den lokalen Rechner übertragen und mit put Daten auf dem externen Rechner speichern. Weiter Kommadno kann man sich mit help bzw. ? anzeigen lassen.

Noch komfortabler ist das mounten:
mount -t smbfs -o username=name,password=pw
server/public /data

Ohne Angabe eines Passworts, also password= gilt eine leere Zeichenkette als Passwort.

Teil 3

Infos:

http://www.samba.org
http://mysite.verizon.net/res0yizl/id12.html

Weiterführende Literatur:
Addison-Wesley Verlag Samba 3 - das offizielle Handbuch
Addison-Wesley Verlag Linux Installation, Konfiguration, Anwendung
Addison-Wesley Verlag Unix/Linux Survival Guide
Oreilly Verlag Samba kurz & gut


Ich hoffe euch hat das Tutorial geholfen

Gruß duddits

P.S.: Für weitere Fragen oder Probleme stehe ich gern zur Verfügung.

Content-Key: 18828

Url: https://administrator.de/contentid/18828

Printed on: April 16, 2024 at 08:04 o'clock

Mitglied: 19610
19610 Nov 06, 2005 at 07:28:57 (UTC)
Goto Top
Gute Abhandlung.
Leider viele Rechtschreibfehler, insbesondere massenhaft fehlende Kommas.
Member: duddits
duddits Nov 06, 2005 at 11:05:00 (UTC)
Goto Top
Danke
Leider viele Rechtschreibfehler,
insbesondere massenhaft fehlende Kommas.
Ich arbeite daran, immer wenn ich mal drüber schaue entdecke ich wieder welche.
Member: Schmitt.Mathias
Schmitt.Mathias Nov 07, 2005 at 11:08:03 (UTC)
Goto Top
Sehr gut!
Ich denke bei einem solchen Tutorial kann man locker über die Fehler weg sehen, oder?
Mitglied: 21122
21122 Dec 03, 2005 at 16:00:17 (UTC)
Goto Top
Hi zusammen,
in Richtung dieses Themas habe ich ein aktuelles Problem...
Ich habe seit kurzem eine netzwerkfähige Festplatte und möchte auf diese via ftp zugreifen können. Theoretisch geht das wohl auch, allerdings bekomme ich es nicht konfiguriert.
Daher hier die Bitte um Eure Hilfe!

- Ich nutze einen WLAN DSL Router (T-Sinus 154 DSL)
- Netzwerkfestplatte Lan Drive
- hätte auch ein DnyDNS Konto falls benötigt

Was genau muß ich wie konfigurieren, damit ich das ganze nun wirklich zum Funktionieren bringen kann.
Bitte wirklich alles detailiet (DAU-gerecht).

Vielen Dank Euch,
FELIX
Member: danix
danix Dec 07, 2005 at 18:12:34 (UTC)
Goto Top
Hallo,

wie steht es mit der Datensicherung - das Windows Filesystem NTFY hat sich bewährt immer und immer wieder. Wenn ein Rechner nicht mehr bootet hänge ich das Teil in einen anderen Rechner und greife darauf zu - sauge mir die Daten weg.

Wie sieht das bei Linux aus?

- Welche Möglichkeiten des Datenzugriffs gibt es?
- Welche Filesysteme gibt es und welche sind die besten?
- Wie komme ich an meine Daten im Problemfall?
- Wie kann ich eine Datensicherung auf eine USB HDD eirnichten so dass auch Windows User darauf zugreifen können? Evtl. mit FAT?
- Kann ich ein solches System auf einem Adaptes S-ATA Controller mit Spiegelung betreiben?

Vielen Dank vorab.

Gruß
danix
Member: duddits
duddits Dec 09, 2005 at 11:33:17 (UTC)
Goto Top
Hi,

Welche Filesysteme gibt es und welche sind die besten?

A: Es gibt viele Dateisysteme unter Linux hier mal die gängigsten mit kurzer Erläuterung:

ext2: ext2 (extended filesystem, Version 2) war für viele jahre das dominierende Linux-Dateisystem. Es zeichnet sich durch außerordentliche stabilität und sicherheit aus.
Es unterstützt aber kein Journaling. Nach einen Rechnerabsturz muss daher eine Zeitaufwändige Überprüfung durchgeführt werden.

ext3: Seit 2002 hat ext3 die Nachfolge von ext2 als dominierendes Dateisystem angetreten.
Es ist zu diesem weitegehend kompatibel. Es unterstützt Journaling und ab Kernel 2.6 ACLs.

reiserfs: Das Reiser-Dateisystem, dessen Name sich von seinen Initiator ableitet, war das erste Dateisystem mit Journaling-Funktionen, das den Eingang in den Kernel schafte.
Gegenüber ext2 und ext3 bietet das Reiser-Dateisystem eine höhere Geschwindigkeit mit kleinen vielen Dateien. Gute Tipps zur Verwendung von Reiserfs kann man von der Seiter http://www.namesys.com erhalten.

xfs: xfs ist seit Jahren als Dateisystem auf Workstations der Firma SGI unter dem Betriebssystem IRIX im Einsatz. Es eignet sich insbesondere für die Verwaltung sher großer Datenbestände (bis hin in den Terabyte-Bereich). Es untertützt Quotas und erweiterte Attribute (ACLs).
Das Dateisystem kann man im laufenden Betrieb (ohne umount) vergrößert werden, was besonders in Kombination mit LVM sher praktisch ist. Auch die I-Nodes-Anzahl kann im laufenden Betrieb verändert werden. Mehr dazu findet man unter http://oss.sgi.com/project/xfs/

jfs: jfs steht für journaled file system. Es wurde ursprünglich von IBM entwickelt und später auf Linux portiert. Details findet man hier: http://oss.software.ibm.com/developerworks/opensource/jfs/

Welche Möglichkeiten des Datenzugriffs gibt es?

Also du kannst mit Linux auf Fat Partittionen schreiben und lesen. Auf NTFS kannst du nur lesen bzw. du kannst auch die Daten von NTFS ändern aber deren Größer darf sich nicht ändern, aber es ist dringens davon abzuraten da es da schnell zum kompletten Datenverlust der NTFS Partittion kommen kann. Es gibt aber kommerzielle NTFS Treiber, die auch das schreiben von Linux auf NTFS ermöglichen.
Windiws kann auf NTFS und FAt schreiben sowie lesen. Alle anderen Dateisysteme sind für Windows unbekannt, aber auch das gibt es Lösungen (z.B. Explorer2fs für ext2).

Wie komme ich an meine Daten im Problemfall?

Da muss du e am besten wie du es bis jetzt mit NTFS Partittonen gemacht hast. Du baust die Festplatte in einen Linux REchner ein und greifst auf deine DAten zu, oder du bentzt eine Life CD von Linux und mountes die Partittone die du brauchst.
Beim abturz des Systems kannst du die Journaling funktionen nutzen oder die Daten zu Fuß wiederherstellen.

Wie kann ich eine Datensicherung auf eine USB HDD eirnichten so dass auch Windows User darauf zugreifen können? Evtl. mit FAT?

Ja, ich würde auch FAt nutzen können beide Systeme drauf schreiben und lesen.

Kann ich ein solches System auf einem Adaptes S-ATA Controller mit Spiegelung betreiben?

Ja, das kannst du, es kann aber bei eine Hardware Raid äher zu Problemen kommen als bei einen Software Raid (wegen den Treibern) , muss aber nicht.

mfg duddits