BLog

ImprintImpressum
PrivacyDatenschutz
DisclaimerHaftung
Downloads 

File-Services FTP, AFP, SMB und NFS auf dem FreeBSD-Home-Server

File-Services also dateiorientierte Dienste auf einem Server erlauben angemeldeten Clients, auf Dateien und Verzeichnisse auf dem Server zuzugreifen, und bei entsprechender Benutzerberechtigung, diese auch direkt dort anzulegen, zu verändern oder zu löschen, und zwar im wesentlichen so als wenn man die Dateien auf der lokalen Festplatte seines Computers gespeichert hätte. Der interessante Unterschied zum Speichern auf der Festplatte ist, daß auf dem Server mehrere berechtigte Benutzer auf dieselben Verzeichnisse und Dateien zeitgleich zugreifen können.

Berechtigte Benutzer, Benutzerberechtigungen und Verzeichnistruktur

Vor dem Wie (greift man auf Dateien auf dem Server zu), ist eigentlich noch die wichtigere Frage nach dem Wer (darf das überhaupt) zu beantworten. Vom Werk aus gab es auf unserem FreeBSD-Home-Server nur einen Benutzer mit einer Zuordnung zu einer natürlichen Person, nämlich der root-User. Das FreeBSD-System kennt wie jedes andere Unix noch andere User, aber das sind funktionelle, maschinelle User. Der wesentliche Unterschied besteht darin, daß sich natürliche User mit Ihrer Benutzerkennung anmelden können. Dafür wurde ihnen ein Passwort (kann u.U. leer sein), eine sogenannte Login-Shell und ein persönliches Verzeichnis das sog. Home-Verzeichnis zugewiesen. Zur Benutzerverwaltung dient das System-Tool pw(8), und man kann sich zum Beispiel die Benutzer eines FreeBSD-Systems anzeigen lassen, und zwar mit dem Kommando pw usershow -a:

root:*:0:0::0:0:Charlie &:/root:/bin/csh
toor:*:0:0::0:0:Bourne-again Superuser:/root:
daemon:*:1:1::0:0:Owner of many system processes:/root:/usr/sbin/nologin
operator:*:2:5::0:0:System &:/:/usr/sbin/nologin
bin:*:3:7::0:0:Binaries Commands and Source:/:/usr/sbin/nologin
tty:*:4:65533::0:0:Tty Sandbox:/:/usr/sbin/nologin
kmem:*:5:65533::0:0:KMem Sandbox:/:/usr/sbin/nologin
games:*:7:13::0:0:Games pseudo-user:/usr/games:/usr/sbin/nologin
news:*:8:8::0:0:News Subsystem:/:/usr/sbin/nologin
man:*:9:9::0:0:Mister Man Pages:/usr/share/man:/usr/sbin/nologin
sshd:*:22:22::0:0:Secure Shell Daemon:/var/empty:/usr/sbin/nologin
smmsp:*:25:25::0:0:Sendmail Submission User:/var/spool/clientmqueue:/usr/sbin/nologin
mailnull:*:26:26::0:0:Sendmail Default User:/var/spool/mqueue:/usr/sbin/nologin
bind:*:53:53::0:0:Bind Sandbox:/:/usr/sbin/nologin
proxy:*:62:62::0:0:Packet Filter pseudo-user:/nonexistent:/usr/sbin/nologin
_pflogd:*:64:64::0:0:pflogd privsep user:/var/empty:/usr/sbin/nologin
_dhcp:*:65:65::0:0:dhcp programs:/var/empty:/usr/sbin/nologin
uucp:*:66:66::0:0:UUCP pseudo-user:/var/spool/uucppublic:/usr/local/libexec/uucp/uucico
pop:*:68:6::0:0:Post Office Owner:/nonexistent:/usr/sbin/nologin
auditdistd:*:78:77::0:0:Auditdistd unprivileged user:/var/empty:/usr/sbin/nologin
www:*:80:80::0:0:World Wide Web Owner:/nonexistent:/usr/sbin/nologin
hast:*:845:845::0:0:HAST unprivileged user:/var/empty:/usr/sbin/nologin
nobody:*:65534:65534::0:0:Unprivileged user:/nonexistent:/usr/sbin/nologin
unbound:*:59:59::0:0:Unbound DNS Resolver:/var/unbound:/usr/sbin/nologin
dhcpd:*:136:136::0:0:ISC DHCP daemon:/nonexistent:/usr/sbin/nologin

Der erste User im System ist root. Er darf im System alles, und er wird daher auch als Superuser bezeichnet. Er hat ein Passwort. Sein Home-Verzeichnis ist /root und seine Login-Shell ist von Haus aus /bin/csh. Alle anderen User haben kein Passwort und die meisten könnten sich auch sowieso nicht am System anmelden, denn die Shell ist /usr/sbin/nologin.

Solange unser Home-Server nur einer einzigen Person dient, könnte man es im Prinzip dabei belassen. Allerdings sind die Berechtigungen des Superusers root dermaßen weitgehend, daß es in jedem Fall besser ist, alltägliche Zugriffe und Aufgaben durch Normaluser und nur die Systemeinrichtung und -verwaltung durch den Superuser durchführen zu lassen. So kann man z.B. versehentliche Systemveränderungen besser vermeiden, bespielsweise könnte root ohne weiteres mit dem Befehl rm -rf / das komplette System löschen. Ein User rolf könnte das so nicht.

Ich lege also für mich den User rolf mit dem pw-Befehl an:

pw useradd -n rolf -c "Rolf" -m -s /bin/csh

Hiermit wird der Systembenutzer rolf mit dem Echtnamen „Rolf" zusammen mit seiner Benutzergruppe rolf und seinem privaten Home-Verzeichnis unter /home/rolf erzeugt. Die Anmelde-Shell ist /bin/csh. Die Zuweisung des Passworts erfolgt in einem separaten Schritt mit dem passwd(1)-Befehl:

passwd rolf
>>>>
Changing local password for rolf
New Password: ********
Retype New Password: ********

Das wiederholt man für alle weiteren in Frage kommenden Benutzer(innen) zuhause, in meinem Fall für meine Frau Andréia und für meinen Sohn Nikolas:

pw useradd -n andreia -c "Andréia" -m -s /bin/csh
passwd andreia
pw useradd -n nikolas -c "Nikolas" -m -s /bin/csh
passwd nikolas

Am besten erstellt man auch gleich noch eine gemeinsame Benutzergruppe z.b. familie:

pw groupadd -n familie -M andreia,nikolas,rolf

Durch die oben gezeigten Befehle wurden automatisch die privaten Home-Verzeichnisse der User angelegt:

ls -l /usr/home
>>>>
total 12
drwxr-xr-x  2 andreia  andreia  512 25 Aug 10:32 andreia
drwxr-xr-x  2 nikolas  nikolas  512 25 Aug 10:33 nikolas
drwxr-xr-x  2 rolf     rolf     512 25 Aug 10:09 rolf

Im Grunde sollen auf diese Home-Verzeichnisse ausser natürlich root nur der/die jeweilige Benutzer(in) Zugriff haben, und es müssen die Zugriffs-Berechtigungen entsprechend angepaßt werden:

chmod -R o-rwx /usr/home/*

Wichtig: Die Akzeptanz der privaten Verzeichnisse steht und fällt mit dem Glauben an ihre Unantastbarkeit. Der Superuser root darf nicht seine technisch begründeten Berechtigungen für schäbige, unberechtigte Schnüffeleien mißbrauchen. Das gilt in großen Organisationen ebenso wie in einer kleinen Organisation wie meiner Familie. Ab sofort hat also root in den obigen privaten Verzeichnissen nichts mehr verloren.

Gemeinsame Daten

Für den Zugriff auf, und den Austausch von gemeinsamen Daten erzeugt man ein separates Basisverzeichnis /usr/files mit sinnvollen Unterverzeichnissen. Dabei ist es nützlich, jedem Benutzer wieder ein eigenes Verzeichnis zuzuweisen. Diese Verzeichnisse sollen semi-privat sein, d.h. der jeweilige Eigentümer entscheidet was er einstellt bzw. auch wieder entfernt, und alle anderen können diese Daten zwar lesen aber nicht selbst an Ort und Stelle verändern. Um den semi-privaten im Gegensatz zum privaten Charakter der Home-Verzeichnisse zu unterstreichen, verwende ich für die Namen Groß-/Kleinschreibung sowie Umlaute und Akzente wenn angebracht - FreeBSD kann wie alle modernen Betriebssysteme UTF-8, man darf alle Zeichen auch Leerzeichen benutzen - Käthe Müller ist also kein Problem und Leute, die daraus KATMUELL machen, sind offenbar immer noch im MS-DOS-8.3-Stockholm-Syndrom gefangen.

mkdir -m 770 /usr/files
mkdir -m 750 /usr/files/Andréia
mkdir -m 750 /usr/files/Nikolas
mkdir -m 750 /usr/files/Rolf

Die Zugriffsberechtigungen müssen noch modifiziert werden:

chgrp -R familie /usr/files
chown -R andreia /usr/files/Andréia
chown -R nikolas /usr/files/Nikolas
chown -R rolf /usr/files/Rolf

Danach sieht es im gemeinsamen Verzeichnis /usr/files wie folgt aus:

ls -l /usr/files
>>>>
total 12
drwxr-x---  2 andreia  familie  512 25 Aug 11:16 Andréia
drwxr-x---  2 nikolas  familie  512 25 Aug 11:17 Nikolas
drwxr-x---  2 rolf     familie  512 25 Aug 11:18 Rolf

Im Verzeichnis /usr/files selbst haben alle Familienmitglieder Lese-/Schreibberechtigungen, und können und sollen hierin selber neue Unterverzeichnisse anlegen bzw. Dateien für alle hinterlegen können:

ls -ld /usr/files
>>>>
drwxrwx--x  12 root  familie  512 Aug 25 11:15 /usr/files

Separates Verzeichnis für Client-Backups

Verzeichnisse, deren Inhalte maschinell, also nicht durch direkten Zugriff des jeweiligen Benutzers auf das Dateisystem, verwaltet werden, müssen separat gehalten werden. Hierunter fallen u.a. E-Mail-Stores, Datenbank-Container, SCM-Repositories, ..., sowie insbesondere auch das Zielverzeichnis für automatische Client-Backup-Systeme wie Time Machine von Apple und ähnliche Tools für Windows.

Zur Aufnahme von Client-Backups erzeugt man das Verzeichnis /usr/backups, und zwar mit denselben Zugriffsberechtigungen wie /usr/files:

mkdir -m 770 /usr/backups
chgrp familie /usr/backups

Installation und -Einrichtung der diversen Netzwerk-Dateisysteme

Üblicherweise kommen die Client-Betriebssystem mit einer Auswahl an Netzwerk-Dateisystemen zurecht. Das Lieblingsprotokoll von Windows ist SMB - Server Message Block. Mac OS X bevorzugt AFP - Apple Filing Protocol, kommt aber auch sehr gut mit SMB klar - Time Machine geht aber nur über AFP. Unix-Systeme tauschen auch mal gerne Dateien über NFS - Network File System aus, allerdings werden hier die Zugriffsberechtigungen nicht über die Anmeldung von Benutzern sondern über die auf dem Servern hinterlegten IP-Adressen der zugelassenen Clients geregelt, NFS ist daher weniger flexibel und wenn man *BSD-, Linux- oder andere Unix-Clients im Haus hat, dann verwendet man für den normalen Dateizugriff am besten SMB. Alle Clients können das gute alte FTP - File Transfer Protocol. In unsicheren Umgebungen sollte man es nicht mehr benutzen, weil alles (auch die Anmeldedaten) in Klartext über die Leitung geht - aber das ist jedenfalls bei uns zu Hause im LAN kein Problem. Mobile Clients mit iOS bzw. Android bedient man je nach darauf installierter App mit SMB, AFP, FTP oder auch WebDAV.

WebDAV ist wie es der Name andeutet ein Dateisystem, das im Web funktioniert. Es handelt sich dabei um eine Erweiterung des HTTP - Hypertext Transfer Protocol und hierfür benötigen wir unseren eigenen Domain-Namen mit eigenem SSL-Zertifikat und wir müssen vorher auch noch einen Web-Server aufsetzen. Das alles kriegen wir später. Ausser WebDAV richten wir also jetzt erstmal alles andere ein.

Der FTP-Service

Ein FTP-Service-Daemon ftpd(8) ist seit Ewigkeiten Bestandteil des FreeBSD-Basissystems, und er muß eigentlich nur gestartet werden. Dazu fügt man einen entsprechenden Eintrag zum Systemstart-Script /etc/rc.conf hinzu:

nano /etc/rc.conf
...

## File Services
ftpd_enable="YES"
ftpd_flags="-8 -u 0007 -a 192.168.1.35"

Auf gar keinen Fall soll der FTP-Server fremden Zugriff von ausserhalb unseres LAN's erlauben und deshalb beschränkt man seine Bereitschaft mit der Option -a <IP> auf die interne LAN-IP-Adresse des Home-Servers, hier 192.168.1.35 (ggf. anpassen). Jetzt kann man den FTP-Daemon starten:

service ftpd start

Mit einem FTP-Client (hier unter Mac OS X) kann man sich nun mit User-Namen und Passwort anmelden:

Wenn man beim Login keine weiteren Angaben macht, dann landet man automatisch in seinem privaten Home-Verzeichnis. Das ist natürlich noch leer weil wir es ja soeben erst angelegt hatten. Man kann von hieraus durch das Dateisystem navigieren und sich z.B. bis zum gemeinsamen Daten-Verzeichnis /usr/files hangeln. Damit man in Zukunft direkt dorthin kommt, erzeugen wir in den Home-Verzeichnissen je ein Alias (Symbolic Link) auf die gemeinsamen Daten:

ln -s /usr/files "/home/andreia/Gemeinsame Daten"
ln -s /usr/files "/home/nikolas/Gemeinsame Daten"
ln -s /usr/files "/home/rolf/Gemeinsame Daten"

Die Verzeichnisansicht des FTP-Clients wird aktualisiert und das Alias ist bereits zu sehen:

Und das Alias bringt uns auch direkt zu den Gemeinsamen Daten:

Alle Familienmitglieder können sich nunmehr per FTP anmelden und haben Zugriff auf die jeweiligen privaten, semi-privaten und gemeinsamen Verzeichnisse.

Der AFP-Service mit Netatalk

Damit der FreeBSD-Home-Server mit dem Apple Filing Protocol dienen kann, muß die Open-Source-Software Netatalk installiert werden. Die Standardkonfiguration des FreeBSD-Binär-Pakets ist allerdings für unsere Zwecke nicht so gut geeignet, denn es wird damit zusätzlich der Multicast-DNS-Dienst Avahi installiert, der eine Fülle unnötiger Funktionen mitbringt, und im Gegenzug erhält man nur eine einzige halbwegs interessante Funktion, die sich einfacher und kompletter, nämlich für alle File-Service (nicht nur AFP) auf anderem Wege, nämlich mit dem net/mDNSResponder erzielen läßt - mehr dazu im Folgeartikel.

Jedenfalls heißt das, daß wir Netatalk in einer angepaßten Konfiguration aus dem FreeBSD-Ports-System heraus kompilieren müssen und nicht als vorkonfiguriertes Binärpaket installieren können. Vor einer Installation über das Ports-System ist es sinnvoll, das Ports-Verzeichnis manuell zu aktualisieren:

portsnap fetch update

Mit der folgenden Befehlssequenz wird net/netatalk3 installiert:

cd /usr/ports/net/netatalk3
make install clean

Es erscheint ein Dialogfeld in dem die verschiedenen Konfigurationsoptionen für Netatalk ausgewählt werden können. Am besten entfernt man zunächst alle Voreinstellungen und markiert danach nur die Optionen ACL und SENDFILE:

Man bestätigt die Auswahl mit <ENTER>, und es werden die Konfigurationsoptionen für weitere Softwarepakete, die Netatalk voraussetzt, angezeigt. Hierbei werden durch Drücken der Taste <ENTER> jeweils einfach die voreingestellten Optionen übernommen.

Bevor Netatalk gestartet werden kann müssen in die Konfigurationsdatei /usr/local/etc/afp.conf die notwendigen Informationen über die Benutzerberechtigungen und die Dateihierarchie, auf die die Clients über den AFP-Dienst zugreifen sollen, eingetragen werden - s. afp.conf(5). Vorher löscht man am besten die mitgelieferte Datei, die nur vergleichsweise nutzlose schablonenartige Einträge enthält:

rm /usr/local/etc/afp.conf
nano /usr/local/etc/afp.conf

Folgendes läßt den AFP-Service die Home-Verzeichnisse der User unter ihrem jeweiligen Namen, das Verzeichnis für die gemeinsamen Daten unter dem Namen Files sowie das Verzeichnis für die automatischen Backups (für Time Machine) unter dem Namen Backups im Netzwerk bereitstellen:

[Global]
zeroconf            = no
afp interfaces      = em0
vol preset          = Volume_Defaults

[Volume_Defaults]
convert appledouble = no
directory perm      = 0770
file perm           = 0660
umask               = 0007

[Homes]
home name           = $u
basedir regex       = /usr/home
file perm           = 0600
veto files          = Gemeinsame Daten/

[Files]
path                = /usr/files
valid users         = @familie

[Backups]
time machine        = yes
path                = /usr/backups
valid users         = @familie

Um den AFP-Dienst starten zu können, aktiviert man Netatalk zunächst im Systemstart-Script /etc/rc.conf unter der Rubrik File Services:

nano /etc/rc.conf
...

## File Services
ftpd_enable="YES"
ftpd_flags="-8 -u 0007 -a 192.168.1.35“
netatalk_enable="YES“​

Schließlich startet man den AFP-Server mit:

service netatalk start

Man kann sich nun von Mac OS X aus mit dem AFP-Server verbinden. Im Finder-Menü Gehe zu wählt man den Menü-Punkt Mit Server verbinden ... (ganz unten) aus:

Der SMB-Service mit Samba

Samba ist eine Open Source Software, mit der man unter Unix-Systemen typische Windows-Funktionen wie File- und Print-Services zur Verfügung stellen kann. Samba kommt mit unzähligen sinnvollen und sinnlosen Konfigurationsmöglichkeiten daher, und wie schon bei Netatalk im vorigen Abschnitt, ist es sinnvoll, sich auf eine kleine Auswahl zu beschränken. Daher wird hier auch Samba nicht als vorkonfiguriertes Binärpaket installiert sondern aus dem FreeBSD-Ports-System heraus konfiguriert und kompiliert:

portsnap fetch update

Mit der folgenden Befehlssequenz installiert man net/samba47:

cd /usr/ports/net/samba47
make install clean

Es erscheint ein Dialogfeld in dem die verschiedenen Konfigurationsoptionen für Samba ausgewählt werden können. Wir beschränken uns auf das Nötigste, denn Samba 4 ist auch ohne den ganzen Firlefanz schon ein richtig fetter Hund:

Man bestätigt die Auswahl mit <ENTER>, und es werden die Konfigurationsoptionen für weitere Softwarepakete, die Samba voraussetzt, angezeigt. Hierbei werden durch Drücken der Taste <ENTER> jeweils einfach die voreingestellten Optionen übernommen.

Bevor der SMB-Service aktiviert und genutzt werden kann, muß er konfiguriert werden - siehe smb4.conf(5). Mit dem Editor nano(1) erzeugt man die Datei /usr/local/etc/smb4.conf:

nano /usr/local/etc/smb4.conf

Man macht die folgenden Eintragungen und speichert die so erzeugte Datei mit <ctrl>-<o> und beendet dann nano mit <ctrl>-<x>:

[global]
workgroup = ZUHAUSE
server string = Server
security = user
encrypt passwords = yes
log level = 0
max log size = 500
preferred master = yes
hosts allow = 192.168.1.
interfaces = em0
bind interfaces only = yes
socket options = TCP_NODELAY
ntlm auth = yes

[homes]
comment = Privater Ordner
browseable = no
writeable = yes
directory mask = 0700
create mask = 0700
veto files = Gemeinsame Daten/

[Files]
comment = Gemeinsame Daten
path = /usr/files
public = no
writeable = yes
write list = @familie
directory mask = 0770
create mask = 0770

[Backups]
comment = Datensicherungen
path = /usr/backups
public = no
writeable = yes
write list = @familie
directory mask = 0750
create mask = 0750

Sowohl unter Unix als auch unter Windows werden Passworte nicht im Klartext im System hinterlegt, sondern sie werden über eine Kryptologische Hashfunktion in einen einmaligen Hash-Wert konvertiert und nur dieser wird für die Authentizitätsprüfung verwendet. FreeBSD nutzt dazu von Haus aus den SHA512-Algorithmus wohingegen Windows mit dem MD4-Algorithmus arbeitet. Damit sich Windows- und andere SMB-Clients an unserem SMB-Server anmelden können, müssen wir die Passworte aller betroffenen User ein zweites Mal, und zwar dieses mal Windows-kompatibel, abspeichern. Dazu dient das in Samba 4 enthaltene Tool pdbedit(8):

pdbedit -a -u rolf
>>>>
new password: ********
retype new password: ********
Unix username:        rolf
NT username:          
Account Flags:        [U          ]
User SID:             S-1-5-21-2059378584-1459378584-359378584-1000
Primary Group SID:    S-1-5-21-2059378584-1459378584-359378584-513
Full Name:            Rolf
Home Directory:       \\server\rolf
HomeDir Drive:        
Logon Script:         
Profile Path:         \\server\rolf\profile
Domain:               SERVER
Account desc:         
Workstations:         
Munged dial:          
Logon time:           0
Logoff time:          So, 04 Dez 219250468 13:30:07 BRST
Kickoff time:         So, 04 Dez 219250468 13:30:07 BRST
Password last set:    Fr, 29 Aug 2014 09:14:10 BRT
Password can change:  Fr, 29 Aug 2014 09:14:10 BRT
Password must change: never
Last bad password   : 0
Bad password count  : 0
Logon hours         : FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
pdbedit -a -u andreia
>>>>
new password: ********
retype new password: ********
Unix username:        andreia
...
...
pdbedit -a -u nikolas
>>>>
new password: ********
retype new password: ********
Unix username:        nikolas
...
...

Der Samba-Server muß nur noch im Systemstart-Script /etc/rc.conf aktiviert werden und kann schließlich gestartet werden:

nano /etc/rc.conf
...

## File Services
ftpd_enable="YES"
ftpd_flags="-8 -u 0007 -a 192.168.1.35"
netatalk_enable="YES“
samba_server_enable="YES"​
service samba_server start

Man kann nun auf die betreffenden Verzeichnisse des FreeBSD-Home-Servers auch von einem Windows-Client aus zugreifen:

Das Network File System

NFS ist anders. Am NFS-Server melden sich keine Benutzer mit Login-Namen und Passwort an, sondern andere Computer-Systeme mit ihren wohl bekannten, registrierten IP-Adressen. Das Nutzungskonzept ist also nicht benutzerorientiert. Benutzer die mit verschiedenen Geräten (Arbeitsplatzrechner, Notebook, Smart-Phone, etc.) von den unterschiedlichsten Orten, sei es von zu Hause im LAN, von unterwegs per VPN oder gar von beliebigen Internet-Cafés im WAN auf ihre Daten zugreifen möchten, schauen bei NFS in die Röhre.

NFS kommt sowieso nur in einem überschaubaren Netzwerk wie unserem Home-LAN in Frage, denn die Sicherheit von NFS steht und fällt damit ob nichtautorisierte Personen in der Lage sind manipulierte Geräte in das Netzwerk einzuhängen. Wir müssen auf jeden Fall unsere WLAN-Access-Points sichern, und z.B. vor wilden Parties im Haus, fährt man am besten NFS sogar herunter, denn wer weiß schon, was der Freund der Schwester der Freundin des Sohnes so alles drauf hat, und vor allem wer will nach dem 5ten Bier noch zählen, welche neuen Geräte im heimischen Netz plötzlich dazugekommen sind.

Im Normalfall bietet sich NFS dann an, wenn man von ein und demselben Arbeitsplatzrechner regelmäßig gewisse Daten auf dem Server bearbeiten will/muß, und diese Daten aus irgendwelchen Gründen nicht auf dem Arbeitsplatzrechner gehalten werden sollen/können. File-Sharing gehört jedenfalls gerade nicht zu den herausragenden Gründen, das geht zwar mit NFS im Prinzip, aber die anderen benutzerorientierten Systeme sind hierbei deutlich im Vorteil.

Ich zeige hier ein Anwendungsbeispiel, daß so mit den anderen Datei-Diensten nicht geht. Ich, der Admin des FreeBSD-Home-Servers bei mir zu Hause, möchte die Konfigurationsdateien als root-User direkt an meinem Mac (hat die feste IP-Adresse 192.168.1.11) mit TextEdit, oder die Web-Applikationen direkt mit Xcode bearbeiten können, denn nano über ssh ist zwar schön, aber TextEdit oder gar Xcode sind noch viel schöner.

Dazu erstelle ich auf dem FreeBSD-Home-Server die Datei /etc/exports mit dem folgenden Inhalt:

nano /etc/exports
/ -mapall=root -alldirs 192.168.1.11
V4: /

Damit wird die komplette Verzeichnishierarchie des Home-Servers ausgehend von / zwecks Exports via NFS für das System mit der IP-Adresse 192.168.1.11 bereitgestellt. Die Option -alldirs bedeutet, daß auch alle Unterverzeichnisse separat als Netzwerklaufwerk aktivierbar sind. Die Option -mapall=root bewirkt, daß z.B. der User rolf vom NFS-Client aus mit root-Rechten auf dem Server agieren kann.

Um den NFS-Diest zu konfigurieren, müssen die folgenden zusätzlichen Direktiven zum Systemstart-Script /etc/rc.conf unter der Rubrik File-Services hinzugefügt werden:

...

## File Services
ftpd_enable="YES"
ftpd_flags="-8 -u 0007 -a 192.168.1.35"
netatalk_enable="YES"
samba_server_enable="YES“
rpcbind_flags="-h 192.168.222.35"
rpc_lockd_flags="-h 192.168.1.35 -p 997"
rpc_statd_flags="-h 192.168.1.35 -p 998"
mountd_flags="-r -h 192.168.1.35 -p 999"
nfs_server_flags="-t -h 192.168.1.35"
rpcbind_enable="YES"
rpc_lockd_enable="YES"
rpc_statd_enable="YES"
mountd_enable="YES"
nfs_client_enable="YES"
nfs_server_enable="YES"
nfsv4_server_enable="YES"
nfsuserd_enable="YES“​

Schließlich startet das folgende Kommando die NFS-Dienste:

service nfsd start

Um sich von Mac OS X aus mit dem so eingerichteten NFS-Server zu verbinden, wählt man im Finder-Menü Gehe zu den Menü-Punkt Mit Server verbinden ... (ganz unten) aus:

Man klickt auf Verbinden und auf dem Desktop erscheint das Laufwerk-Symbol für den Server:

Man öffnet das Verzeichnisfenster des Laufwerks durch Doppelklick:

Alles da! Und so sieht dann /tmp/Server/etc/rc.conf in TextEdit aus:

Ich kann die Datei bearbeiten und speichern, und zwar mit denselben effektiven Rechten, die ich hätte wenn ich den Kommandozeilen-Editor nano via ssh direkt auf dem Server verwenden würde.

Das ging jetzt wirklich nur mit NFS. Mir fallen allerdings kaum gute andere Anwendungsbeispiele ein, die sich nicht besser mit den anderen oben aufgeführten File-Services erledigen ließen.

Copyright © Dr. Rolf Jansen - 2014-08-30 02:51:59

PROMOTION