29.3. Netwerkbestandssysteem (NFS)
Terug | Hoofdstuk 29. Netwerkdiensten | Volgende

## 29.3. Netwerkbestandssysteem (NFS)

Gereorganiseerd en verbeterd door Tom Rhodes.
Geschreven door Bill Swingle.

Het Netwerkbestandssysteem (Network File System) is een van de vele bestandssystemen die FreeBSD ondersteunt. Het staat ook wel bekend als NFS. Met NFS is het mogelijk om mappen en bestanden met anderen in een netwerk te delen. Door het gebruik van NFS kunnen gebruikers en programma's bij bestanden op andere systemen op bijna dezelfde manier als bij hun eigen lokale bestanden.

De grootste voordelen van NFS zijn:

- Lokale werkstations gebruiken minder schijfruimte omdat veel gebruikte data op één machine opgeslagen kan worden en nog steeds toegankelijk is voor gebruikers via het netwerk;

- Gebruikers hoeven niet op iedere machine een thuismap te hebben. Thuismappen kunnen op de NFS server staan en op het hele netwerk beschikbaar zijn;

- Opslagapparaten als floppydisks, CD-ROM drives en Zip® drives kunnen door andere machines op een netwerk gebruikt worden. Hierdoor kan het aantal drives met verwijderbare media in een netwerk verkleind worden.

### 29.3.1. Hoe NFS werkt

NFS bestaat uit tenminste twee hoofdonderdelen: een server en een of meer cliënten. De cliënt benadert de gegevens die op een servermachine zijn opgeslagen via een netwerk. Om dit mogelijk te maken moeten er een aantal processen ingesteld en gestart worden.

Op de server moeten de volgende daemons draaien:

Daemon | Beschrijving
--- | ---
nfsd | De NFS-daemon die verzoeken van de NFS cliënten afhandelt.
mountd | De NFS koppeldaemon die doorgestuurde verzoeken van nfsd(8) uitvoert.
rpcbind | Deze daemon geeft voor NFS-cliënten aan welke poort de NFS-server gebruikt.

Op de cliënt kan ook een daemon draaien: nfsiod. De daemon nfsiod handelt verzoeken van de NFS-server af. Dit is optioneel en kan de prestaties verbeteren, maar het is niet noodzakelijk voor een normale en correcte werking. Meer informatie staat in nfsiod(8).

### 29.3.2. NFS instellen

NFS instellen gaat redelijk rechtlijnig. Alle processen die moeten draaien kunnen meestarten bij het opstarten door een paar wijzigingen in `/etc/rc.conf`.

Op de NFS server dienen de volgende opties in `/etc/rc.conf` te staan:

rpcbind_enable="YES" nfs_server_enable="YES" mountd_flags="-r"

mountd start automatisch als de NFS server is ingeschakeld.

Op de cliënt dient de volgende optie in `/etc/rc.conf` te staan:

nfs_client_enable="YES"

In het bestand `/etc/exports` staat beschreven welke bestandssystemen NFS moet exporteren (soms heet dat ook wel delen of “sharen”). Iedere regel in `/etc/exports` slaat op een bestandssysteem dat wordt geëxporteerd en welke machines toegang hebben tot dat bestandssysteem. Samen met machines die toegang hebben, kunnen ook toegangsopties worden aangegeven. Er zijn veel opties beschikbaar, maar hier worden er maar een paar beschreven. Alle opties staan beschreven in exports(5).

Nu volgen een aantal voorbeelden voor `/etc/exports`:

Het volgende voorbeeld geeft een beeld van hoe een bestandssysteem te exporteren, hoewel de instellingen afhankelijk zijn van de omgeving en het netwerk. Om bijvoorbeeld de map `/cdrom` te exporteren naar drie machines die dezelfde domeinnaam hebben als de server (vandaar dat de machinenamen geef domeinachtervoegsel hebben) of in `/etc/hosts` staan. De vlag `-ro` exporteert het bestandssysteem als alleen–lezen. Door die vlag kan een ander systeem niet schrijven naar het geëxporteerde bestandssysteem.

/cdrom -ro host1 host2 host3

Het volgende voorbeeld exporteert `/home` naar drie hosts op basis van IP-adres. Dit heeft zin als er een privaat netwerk bestaat, zonder dat er een DNS server is ingesteld. Optioneel kan `/etc/hosts` gebruikt worden om interne hostnamen in te stellen. Er is meer informatie te vinden in hosts(5). Met de vlag `-alldirs` mogen submappen ook koppelpunten zijn. De submap wordt dan niet feitelijk aangekoppeld, maar de cliënt koppelt dan alleen de submappen aan die verplicht of nodig zijn.

/home -alldirs 10.0.0.2 10.0.0.3 10.0.0.4

Het volgende voorbeeld exporteert `/a` zo dat twee cliënten uit verschillende domeinen bij het bestandssysteem mogen. Met de vlag `–maproot=root` mag de gebruiker op het andere systeem gegevens naar het geëxporteerde bestandssysteem schrijven als `root`. Als de vlag `-maproot=root` niet wordt gebruikt, dan kan een gebruiker geen bestanden wijzigen op het geëxporteerde bestandssysteem, zelfs niet als een gebruiker daar `root` is.

/a -maproot=root host.example.com box.example.org

Om een cliënt toegang te geven tot een geëxporteerd bestandssysteem, moet die cliënt daar rechten voor hebben. De cliënt moet daarvoor genoemd worden in `/etc/exports`.

In `/etc/exports` staat iedere regel voor de exportinformatie van één bestandssysteem naar één host. Per bestandssysteem mag een host maar één keer genoemd worden en mag maar één standaard hebben. Stel bijvoorbeeld dat `/usr` een enkel bestandssysteem is. Dan is de volgende `/etc/exports` niet geldig:

># Werkt niet als /usr 1 bestandssysteem is /usr/src client /usr/ports client

Eén bestandssysteem, `/usr`, heeft twee regels waarin exports naar dezelfde host worden aangegeven, `client`. In deze situatie is de juiste instelling:

/usr/src /usr/ports client

De eigenschappen van een bestandssysteem dat naar een bepaalde host wordt geëxporteerd moeten allemaal op één regel staan. Regels waarop geen cliënt wordt aangegeven worden behandeld als een enkele host. Dit beperkt hoe bestandssysteem geëxporteerd kunnen worden, maar dat blijkt meestal geen probleem te zijn.

Het volgende voorbeeld is een geldige exportlijst waar `/usr` en `/exports` lokale bestandssystemen zijn:

# Exporteer src en ports naar client01 en client02, # maar alleen client01 heeft er rootprivileges /usr/src /usr/ports -maproot=root client01 /usr/src /usr/ports client02 # De cliëntmachines hebben rootrechten en kunnen overal aankoppelen # op /exports. Iedereen in de wereld kan /exports/obj als alleen-lezen aankoppelen. /exports -alldirs -maproot=root client01 client02 /exports/obj -ro

De daemon mountd moet gedwongen worden om het bestand `/etc/exports` te controleren steeds wanneer het is aangepast, zodat de veranderingen effectief kunnen worden. Dit kan worden bereikt door òfwel een HUP-signaal naar de draaiende daemon te sturen:

`#` `kill -HUP `cat /var/run/mountd.pid``

of door het rc(8) script `mountd` met de juiste parameter aan te roepen:

`#` `service mountd onereload`

Raadpleeg Paragraaf 12.7, “Gebruik van rc met FreeBSD” voor meer informatie over het gebruik van rc-scripts.

Het is ook mogelijk een machine te herstarten, zodat FreeBSD alles netjes in kan stellen, maar dat is niet nodig. Het uitvoeren van de volgende commando's als `root` hoort hetzelfde resultaat te hebben.

Op de NFS server:

`#` `rpcbind` `#` `nfsd -u -t -n 4` `#` `mountd -r`

Op de NFS cliënt:

`#` `nfsiod -n 4`

Nu is alles klaar om feitelijk het netwerkbestandssysteem aan te koppelen. In de volgende voorbeelden is de naam van de server `server` en de naam van de cliënt is `client`. Om een netwerkbestandssysteem slechts tijdelijk aan te koppelen of om alleen te testen, kan een commando als het onderstaande als `root` op de cliënt uitgevoerd worden:

`#` `mount server:/home /mnt`

Hiermee wordt de map `/home` op de server aangekoppeld op `/mnt` op de cliënt. Als alles juist is ingesteld, zijn nu in `/mnt` op de cliënt de bestanden van de server zichtbaar.

Om een netwerkbestandssysteem iedere keer als een computer opstart aan te koppelen, kan het bestandssysteem worden toegevoegd aan het bestand `/etc/fstab`:

server:/home /mnt nfs rw 0 0

Alle beschikbare opties staan in fstab(5).

### 29.3.3. Op slot zetten

Voor sommige applicaties (b.v. mutt) is het nodig dat bestanden op slot staan om correct te werken. In het geval van NFS, kan rpc.lockd worden gebruikt voor het op slot zetten van bestanden. Voeg het volgende toe aan het bestand `/etc/rc.conf` op zowel de cliënt als de server om het aan te zetten (het wordt aangenomen dat de NFS-cliënt en -server reeds zijn geconfigureerd):

rpc_lockd_enable="YES" rpc_statd_enable="YES"

Start de applicatie met:

`#` `service lockd start` `#` `service statd start`

Als echt op slot zetten tussen de NFS-cliënten en de NFS-server niet nodig is, is het mogelijk om de NFS-cliënt bestanden lokaal op slot te laten zetten door `-L` aan mount_nfs(8) door te geven. In de handleidingpagina mount_nfs(8) staan verdere details.

### 29.3.4. Mogelijkheden voor gebruik

NFS is voor veel doeleinden in te zetten. Een aantal voorbeelden:

- Een aantal machines een CD-ROM of andere media laten delen. Dat is goedkoper en vaak ook handiger, bijvoorbeeld bij het installeren van software op meerdere machines;

- Op grote netwerken kan het praktisch zijn om een centrale NFS server in te richten, waarop alle thuismappen staan. Die thuismappen kunnen dan geëxporteerd worden, zodat gebruikers altijd dezelfde thuismap hebben, op welk werkstation ze ook aanmelden;

- Meerdere machines kunnen een gezamenlijke map `/usr/ports/distfiles` hebben. Dan is het mogelijk om een port op meerdere machines te installeren, zonder op iedere machine de broncode te hoeven downloaden.

### 29.3.5. Automatisch aankoppelen met amd

Geschreven door Wylie Stilwell.
Herschreven door Chern Lee.

amd(8) (de automatic mounter daemon) koppelt automatisch netwerkbestandssystemen aan als er aan een bestand of map binnen dat bestandssysteem wordt gerefereerd. amd ontkoppelt ook bestandssystemen die een bepaalde tijd niet gebruikt worden. Het gebruikt van amd is een aantrekkelijk en eenvoudig alternatief ten opzichte van permanente koppelingen, die meestal in `/etc/fstab` staan.

amd werkt door zichzelf als NFS-server te koppelen aan de mappen `/host` en `/net`. Als binnen die mappen een bestand wordt geraadpleegd, dan zoekt amd de bijbehorende netwerkkoppeling op en koppelt die automatisch aan. `/net` wordt gebruikt om een geëxporteerd bestandssysteem van een IP-adres aan te koppelen, terwijl `/host` wordt gebruikt om een geëxporteerd bestandssysteem van een hostnaam aan te koppelen.

Het raadplegen van een bestand in `/host/foobar/usr` geeft amd aan dat die moet proberen de `/usr` export op de host `foobar` aan te koppelen.

Voorbeeld 29.2. Een export aankoppelen met amd

De beschikbare koppelingen van een netwerkhost zijn te bekijken met `showmount`. Om bijvoorbeeld de koppelingen van de host `foobar` te bekijken:

`%` `showmount -e foobar` Exports list on foobar: /usr 10.10.10.0 /a 10.10.10.0 `%` `cd /host/foobar/usr`

Zoals in het bovenstaande voorbeeld te zien is, toont `showmount` `/usr` als een export. Als er naar de map `/host/foobar/usr` wordt gegaan, probeert amd de hostnaam `foobar` te resolven en de gewenste export automatisch aan te koppelen.

amd kan gestart worden door de opstartscript door de volgende regel in `/etc/rc.conf` te plaatsen:

amd_enable="YES"

Er kunnen ook nog opties meegegeven worden aan amd met de optie `amd_flags`. Standaard staat `amd_flags` ingesteld op:

amd_flags="-a /.amd_mnt -l syslog /host /etc/amd.map /net /etc/amd.map"

In het bestand `/etc/amd.map` staan de standaardinstellingen waarmee exports aangekoppeld worden. In het bestand `/etc/amd.conf` staan een aantal van de meer gevorderde instellingen van amd.

In amd(8) en amd.conf(5) staat meer informatie.

### 29.3.6. Problemen bij samenwerking met andere systemen

Geschreven door John Lind.

Bepaalde Ethernet adapters voor ISA PC systemen kennen limieten die tot serieuze netwerkproblemen kunnen leiden, in het bijzonder met NFS. Dit probleem is niet specifiek voor FreeBSD, maar het kan op FreeBSD wel voor komen.

Het probleem ontstaat bijna altijd als (FreeBSD) PC-systemen netwerken met hoog presterende werkstations, zoals van Silicon Graphics, Inc. en Sun Microsystems, Inc. De NFS-koppeling werkt prima en wellicht lukken een aantal acties ook, maar dan ineens lijkt de server niet meer te reageren voor de cliënt, hoewel verzoeken van en naar andere systemen gewoon verwerkt worden. Dit gebeurt op een cliëntsysteem, of de cliënt nu het FreeBSD systeem is of het werkstation. Op veel systemen is er geen manier om de cliënt netjes af te sluiten als dit probleem is ontstaan. Vaak is de enige mogelijkheid een reset van de cliënt, omdat het probleem met NFS niet opgelost kan worden.

Hoewel de enige “correcte” oplossing de aanschaf van een snellere en betere Ethernet adapter voor het FreeBSD systeem is, is er zo om het probleem heen te werken dat het werkbaar is. Als FreeBSD de server is, kan de optie `-w=1024` gebruikt worden bij het aankoppelen door de cliënt. Als het FreeBSD systeem de cliënt is, dan dient het NFS-bestandssysteem aangekoppeld te worden met de optie `r=1024`. Deze opties kunnen het vierde veld zijn in een regel in `fstab` voor automatische aankoppelingen en bij handmatige aankoppelingen met mount(8) kan de parameter `-o` gebruikt worden.

Soms wordt een ander probleem voor dit probleem versleten, als servers en cliënten zich op verschillende netwerken bevinden. Als dat het geval is, dan dient vastgesteld te worden dat routers de UDP informatie op de juiste wijze routeren, omdat er anders nooit NFS-verkeer gerouteerd kan worden.

In de volgende voorbeelden is `fastws` de host(interface)naam van een hoog presterend werkstation en `freebox` is de host(interface)naam van een FreeBSD systeem met een Ethernet adapter die mindere prestaties levert. `/sharedfs` wordt het geëxporteerde NFS-bestandssysteem (zie exports(5)) en `/project` wordt het koppelpunt voor het geëxporteerde bestandssysteem op de cliënt.

### Opmerking:

In sommige gevallen kunnen applicaties beter draaien als extra opties als `hard` of `soft` en `bg` gebruikt worden.

Voorbeelden voor het FreeBSD systeem (`freebox`) als de cliënt in `/etc/fstab` op `freebox`:

fastws:/sharedfs /project nfs rw,-r=1024 0 0

Als een handmatig aankoppelcommando op `freebox`:

`#` `mount -t nfs -o -r=1024 fastws:/sharedfs /project`

Voorbeelden voor het FreeBSD systeem als de server in `/etc/fstab` op `fastws`:

freebox:/sharedfs /project nfs rw,-w=1024 0 0

Als een handmatig aankoppelcommando op `fastws`:

`#` `mount -t nfs -o -w=1024 freebox:/sharedfs /project`

Bijna iedere 16–bit Ethernet adapter werkt zonder de hierboven beschreven restricties op de lees- en schrijfgrootte.

Voor wie het wil weten wordt nu beschreven wat er gebeurt als de fout ontstaan, wat ook duidelijk maakt waarom het niet hersteld kan worden. NFS werkt meestal met een “block”grootte van 8 K (hoewel het mogelijk is dat er kleinere fragmenten worden verwerkt). Omdat de maximale grootte van een Ethernet pakket rond de 1500 bytes ligt, wordt een “block” opgesplitst in meerdere Ethernetpakketten, hoewel het hoger in de code nog steeds één eenheid is, en wordt ontvangen, samengevoegd en bevestigd als een eenheid. De hoog presterende werkstations kunnen de pakketten waaruit een NFS-eenheid bestaat bijzonder snel naar buiten pompen. Op de kaarten met minder capaciteit worden de eerdere pakketten door de latere pakketten van dezelfde eenheid ingehaald voordat ze bij die host zijn aangekomen en daarom kan de eenheid niet worden samengesteld en bevestigd. Als gevolg daarvan ontstaat er op het werkstation een timeout en probeert die de eenheid opnieuw te sturen, maar dan weer de hele eenheid van 8 K, waardoor het proces wordt herhaald, ad infinitum.

Door de grootte van de eenheid kleiner te houden dan de grootte van een Ethernet pakket, is het zeker dat elk Ethernetpakket dat compleet is aangekomen bevestigd kan worden, zodat de deadlock niet ontstaat.

Toch kan een PC systeem nog wel overrompeld worden als hoog presterende werkstations er op inhakken, maar met de betere netwerkkaarten valt het dan in ieder geval niet om door de NFS “eenheden”. Als het systeem toch wordt overrompeld, dan worden de betrokken eenheden opnieuw verstuurd en dan is de kans groot dat ze worden ontvangen, samengevoegd en bevestigd.

Terug | Omhoog | Volgende
29.2. De inetd “Super-Server” | Begin | 29.4. Netwerkinformatiesysteem (NIS/YP)