Scroll to navigation

exports(5) File Formats Manual exports(5)

NUME

exports - tabelul de export al serverului NFS

DESCRIERE

Fișierul /etc/exports conține un tabel al sistemelor de fișiere fizice locale de pe un server NFS care sunt accesibile clienților NFS. Conținutul fișierului este menținut de administratorul de sistem al serverului.

Fiecare sistem de fișiere din acest tabel are o listă de opțiuni și o listă de control al accesului. Tabelul este utilizat de exportfs(8) pentru a furniza informații către mountd(8).

Formatul fișierului este similar cu cel al fișierului exportsal SunOS. Fiecare linie conține un punct de export și o listă separată prin spații albe a clienților cărora li se permite să monteze sistemul de fișiere la acel punct. Fiecare client enumerat poate fi urmat imediat de o listă de opțiuni de export pentru clientul respectiv, separate prin virgule și puse între paranteze. Nu sunt permise spații albe între un client și lista sa de opțiuni.

De asemenea, fiecare linie poate avea una sau mai multe specificații pentru opțiuni implicite după numele rutei, sub forma unei liniuțe („-”) urmată de o listă de opțiuni. Lista de opțiuni este utilizată numai pentru toate exporturile ulterioare pe linia respectivă.

Liniile goale sunt ignorate. Semnul lirei („#”) introduce un comentariu la sfârșitul liniei. Înregistrările pot fi continuate pe linii noi folosind o bară oblică inversă. Dacă un nume de export conține spații, acesta trebuie să fie pus între ghilimele duble. De asemenea, puteți specifica spații sau alte caractere neobișnuite în numele de export folosind o bară oblică inversă urmată de codul caracterului sub forma a trei cifre octale.

Pentru a aplica modificările la acest fișier, executați exportfs -ra sau reporniți serverul NFS.

Formate pentru numele mașinii

Clienții NFS pot fi specificați în mai multe moduri:

Puteți specifica o gazdă fie printr-un nume abreviat recunoscut de rezolvator, fie printr-un nume de domeniu complet calificat, o adresă IPv4 sau o adresă IPv6. Adresele IPv6 nu trebuie să se afle între paranteze drepte în „/etc/exports” pentru a nu fi confundate cu potriviri de caractere de tip joker.
De asemenea, puteți exporta simultan directoare către toate gazdele dintr-o (sub)rețea IP. Acest lucru se realizează prin specificarea unei adrese IP și a unei perechi de măști de rețea ca adresă/mască de rețea, unde masca de rețea poate fi specificată în format zecimal punctat sau ca o lungime de mască contiguă. De exemplu, fie „/255.255.252.0”, fie „/22” adăugate la adresa IPv4 de bază a rețelei rezultă subrețele identice cu 10 biți de gazdă. Adresele IPv6 trebuie să utilizeze o lungime de mască contiguă și nu trebuie să se afle între paranteze drepte pentru a evita confuzia cu caracterele joker de clasă. Caracterele joker nu funcționează în general cu adresele IP, deși pot funcționa accidental atunci când căutările DNS inverse eșuează.
Numele mașinilor pot conține caracterele joker * și ? sau pot conține liste de clase de caractere între [paranteze drepte]. Acest lucru poate fi utilizat pentru a face fișierul exports mai compact; de exemplu, *.cs.foo.edu corespunde tuturor gazdelor din domeniul cs.foo.edu. Deoarece aceste caractere se potrivesc și cu punctele dintr-un nume de domeniu, modelul dat se va potrivi și cu toate gazdele din orice subdomeniu al cs.foo.edu.
Grupurile de rețea NIS pot fi date ca @group. Numai partea de gazdă a fiecărui membru al grupului de rețea este luată în considerare pentru verificarea apartenenței. Părțile de gazdă goale sau cele care conțin o singură liniuță (-) sunt ignorate.
Aceasta este specificată printr-un singur caracter * (a nu se confunda cu caractere joker de mai sus) și se va potrivi tuturor clienților.

Dacă un client corespunde mai multor specificații de mai sus, prima potrivire din lista de mai sus are prioritate - indiferent de ordinea în care apar în linia de export. Cu toate acestea, în cazul în care un client corespunde mai multor specificații de același tip (de exemplu, două grupuri de rețele), atunci are prioritate prima potrivire din ordinea în care apar pe linia de export.

Securitatea RPCSEC_GSS

Puteți utiliza șirurile speciale „gss/krb5”, „gss/krb5i” sau „gss/krb5p” pentru a restricționa accesul clienților care utilizează securitatea rpcsec_gss. Cu toate acestea, această sintaxă este depreciată; pe nucleele linux începând cu versiunea 2.6.23, ar trebui să utilizați în schimb opțiunea de export „sec=”:

Opțiunea sec=, urmată de o listă de tipuri de securitate delimitată prin două puncte, restricționează exportul la clienții care utilizează respectivele tipuri. Tipurile de securitate disponibile includ sys (implicit - nicio securitate criptografică), krb5 (doar autentificare), krb5i (protecție a integrității) și krb5p (protecție a confidențialității). În scopul negocierii variantelor de securitate, ordinea contează: variantele preferate ar trebui să fie enumerate primele. Ordinea opțiunii sec= în raport cu celelalte opțiuni nu contează, cu excepția cazului în care doriți ca anumite opțiuni să fie aplicate în mod diferit în funcție de varianta de securitate. În acest caz, puteți include mai multe opțiuni sec=, iar următoarele opțiuni vor fi puse în aplicare numai pentru accesul care utilizează variantele enumerate în opțiunea sec= imediat anterioară. Singurele opțiuni care pot varia în acest mod sunt ro, rw, no_root_squash, root_squash și all_squash.

Securitatea stratului de transport

Serverul NFS Linux permite utilizarea RPC-cu-TLS (RFC 9289) pentru a proteja traficul RPC între el și clienții săi. Alternativ, administratorii pot securiza traficul NFS utilizând un VPN, un tunel ssh sau un mecanism similar, într-un mod transparent pentru server.

Pentru a permite utilizarea RPC-cu-TLS, administratorul serverului trebuie să instaleze și să configureze tlshd pentru a gestiona cererile de negociere privind securitatea stratului de transport de la nucleul local. Clienții pot alege apoi să utilizeze RPC-cu-TLS sau pot continua să funcționeze fără aceasta.

Administratorii pot solicita utilizarea RPC-cu-TLS pentru a proteja accesul la exporturi individuale. Acest lucru este deosebit de util atunci când se utilizează variante de securitate necriptografice, cum ar fi sec=sys. Opțiunea xprtsec=, urmată de o listă neordonată delimitată de două puncte de politici de securitate, poate restricționa accesul la export numai pentru clienții care au negociat securitatea stratului de transport. Politicile de securitate a stratului de transport acceptate în prezent includ:

Serverul permite clienților să acceseze exportul fără a utiliza securitatea stratului de transport.
Serverul permite clienților care au negociat o sesiune RPC-cu-TLS fără autentificare „peer” (numai confidențialitate) să acceseze exportul. Clienții nu sunt obligați să ofere un certificat x.509 atunci când stabilesc o sesiune de securitate a stratului de transport.
Serverul permite clienților care au negociat o sesiune RPC-cu-TLS cu autentificare „peer”să acceseze exportul. Serverul solicită clienților să ofere un certificat x.509 atunci când stabilesc o sesiune de securitate a stratului de transport.

Dacă RPC-cu-TLS este configurat și activat și opțiunea xprtsec= nu este specificată, valoarea implicită pentru un export este xprtsec=none:tls:mtls. Cu această definiție, serverul permite clienților să utilizeze orice mecanism de securitate a stratului de transport sau niciunul pentru a accesa exportul.

Opțiuni generale

exportfs înțelege următoarele opțiuni de export:

Această opțiune impune ca cererile care nu utilizează gss să provină de pe un port Internet mai mic decât IPPORT_RESERVED (1024). Această opțiune este activată în mod implicit. Pentru a o dezactiva, specificați insecure. (NOTĂ: nucleele mai vechi (înainte de versiunea 4.17 a nucleului din amonte) impuneau această cerință și pentru cererile gss).
Permite atât cererile de citire, cât și cele de scriere pe acest volum NFS. Valoarea implicită este de a nu permite nicio cerere care modifică sistemul de fișiere. Acest lucru poate fi, de asemenea, făcut explicit prin utilizarea opțiunii ro.
Această opțiune permite serverului NFS să încalce protocolul NFS și să răspundă la solicitări înainte ca orice modificări aduse de solicitarea respectivă să fi fost înregistrate în stocarea stabilă (de exemplu, unitatea de disc).

Utilizarea acestei opțiuni îmbunătățește de obicei performanța, dar cu prețul că o repornire necurățată a serverului (de exemplu, o prăbușire) poate cauza pierderea sau deteriorarea datelor.

Răspunde la solicitări numai după ce modificările au fost introduse în stocarea stabilă (a se vedea async de mai sus).

În versiunile de nfs-utils până la 1.0.0 inclusiv, opțiunea async a fost cea implicită. În toate versiunile după 1.0.0, sync este opțiunea implicită, iar async trebuie solicitată explicit dacă este necesar.

Această opțiune nu are niciun efect dacă async este de asemenea definită. Serverul NFS va întârzia în mod normal cu puțin comiterea unei cereri de scriere pe disc dacă suspectează că o altă cerere de scriere conexă poate fi în curs sau poate sosi în curând. Acest lucru permite transmiterea mai multor cereri de scriere pe disc cu o singură operație, ceea ce poate îmbunătăți performanța. Dacă un server NFS primește în principal cereri mici fără legătură, acest comportament ar putea reduce de fapt performanța, astfel încât no_wdelay este disponibilă pentru a o dezactiva. Valoarea implicită poate fi solicitată explicit cu opțiunea wdelay.
Această opțiune se bazează pe opțiunea cu același nume oferită în NFS IRIX. În mod normal, dacă un server exportă două sisteme de fișiere, dintre care unul este montat pe celălalt, clientul va trebui să monteze explicit ambele sisteme de fișiere pentru a avea acces la ele. Dacă montează doar părintele, va vedea un director gol în locul în care este montat celălalt sistem de fișiere. Acest sistem de fișiere este „ascuns”.

Definirea opțiunii nohide pe un sistem de fișiere face ca acesta să nu fie ascuns, iar un client autorizat corespunzător va putea să treacă de la sistemul părinte la acel sistem de fișiere fără să observe schimbarea.

Cu toate acestea, unii clienți NFS nu se descurcă bine cu această situație deoarece, de exemplu, este posibil ca două fișiere din același sistem de fișiere aparent să aibă același număr de nod-i.

Opțiunea nohide este eficientă în prezent numai pentru exporturile către o singură gazdă. Aceasta nu funcționează în mod fiabil cu exporturile către grupuri de rețea, sub-rețea sau clienți numiți cu ajutorul caracterelor joker.

Această opțiune poate fi foarte utilă în anumite situații, dar trebuie utilizată cu atenția cuvenită și numai după confirmarea faptului că sistemul client face față situației în mod eficient.

Opțiunea poate fi dezactivată explicit pentru NFSv2 și NFSv3 cu hide.

Această opțiune nu este relevantă atunci când se utilizează NFSv4. NFSv4 nu ascunde niciodată sistemele de fișiere subordonate. Orice sistem de fișiere care este exportat va fi vizibil acolo unde este de așteptat atunci când se utilizează NFSv4.

Această opțiune este similară cu nohide, dar permite clienților să acceseze toate sistemele de fișiere montate pe un sistem de fișiere marcat cu crossmnt. Astfel, atunci când un sistem de fișiere copil „B” este montat pe un sistem părinte „A”, activarea opțiunii crossmnt pe «A» are un efect similar cu activarea opțiunii „nohide” pe B.

Cu nohide sistemul de fișiere copil trebuie să fie exportat explicit. Cu crossmnt nu este necesar. Dacă un copil al unui fișier crossmnt nu este exportat explicit, atunci acesta va fi exportat implicit cu aceleași opțiuni de export ca și părintele, cu excepția fsid=. Acest lucru face imposibil să nu se exporte un copil al unui sistem de fișiere crossmnt. Dacă unele, dar nu toate sistemele de fișiere subordonate unui părinte trebuie să fie exportate, atunci acestea trebuie să fie exportate explicit, iar părintelui nu trebuie să i se definească crossmnt.

Opțiunea nocrossmnt poate dezactiva în mod explicit crossmnt dacă a fost definită anterior. Acest lucru este rareori util.

Această opțiune activează verificarea subarborelui, care poate avea ușoare beneficii de securitate, dar poate reduce fiabilitatea în anumite circumstanțe.

Dacă un subdirector dintr-un sistem de fișiere este exportat, dar întregul sistem de fișiere nu este, atunci de fiecare dată când sosește o cerere NFS, serverul trebuie să verifice nu numai dacă fișierul accesat se află în sistemul de fișiere corespunzător (ceea ce este ușor), ci și dacă se află în arborele exportat (ceea ce este mai greu). Această verificare se numește subtree_check.

Pentru a efectua această verificare, serverul trebuie să includă unele informații despre locația fișierului în „filehandle” care este dat clientului. Acest lucru poate cauza probleme la accesarea fișierelor care sunt redenumite în timp ce un client le are deschise (deși în multe cazuri simple va funcționa în continuare).

verificarea subarborelui este, de asemenea, utilizată pentru a se asigura că fișierele din interiorul directoarelor la care doar root are acces pot fi accesate numai dacă sistemul de fișiere este exportat cu no_root_squash (a se vedea mai jos), chiar dacă fișierul în sine permite un acces mai general.

Pentru mai multe informații despre implicațiile de securitate, consultați secțiunea «Exporturi de subdirectoare».

Ca un ghid general, un sistem de fișiere de tip „director personal”, care este în mod normal exportat la rădăcină și în care pot apărea multe redenumiri de fișiere, ar trebui să fie exportat cu verificarea sub-arborelui dezactivată. Un sistem de fișiere care este în cea mai mare parte de tip numai-citire și pentru care cel puțin nu există multe redenumiri de fișiere (de exemplu, „/usr” sau „/var”) și pentru care subdirectoarele pot fi exportate, ar trebui probabil să fie exportat cu verificarea sub-arborelui activată.

Verificările implicite ale subarborelui sunt dezactivate și pot fi solicitate explicit cu no_subtree_check.

Înainte de versiunea 1.1.0 a nfs-utils, valoarea implicită era subtree_check. De la versiunea 1.1.0, opțiunea implicită este no_subtree_check, deoarece verificarea subarborelui tinde să cauzeze mai multe probleme decât merită. Dacă aveți într-adevăr nevoie de verificarea subarborelui, trebuie să introduceți explicit această opțiune în fișierul exports. Dacă nu introduceți nicio opțiune, exportfs vă va avertiza că modificarea a avut loc.

Această opțiune (cele două nume sunt sinonime) indică serverului NFS să nu solicite autentificarea cererilor de blocare (adică cererile care utilizează protocolul NLM). În mod normal, serverul NFS va solicita ca o cerere de blocare să dețină o acreditare pentru un utilizator care are acces de citire la fișier. Cu această opțiune nu se va efectua nicio verificare a accesului.

Implementările anterioare ale clienților NFS nu trimiteau acreditări cu cererile de blocare și există încă mulți clienți NFS actuali care se bazează pe implementările vechi. Utilizați acest fanion dacă constatați că puteți bloca numai fișiere care pot fi citite de toată lumea.

Comportamentul implicit de a solicita autentificarea pentru cererile NLM poate fi solicitat în mod explicit cu oricare dintre sinonimele auth_nlm sau secure_locks.

Această opțiune face posibilă exportarea unui director numai dacă acesta a fost montat cu succes. Dacă nu este indicată nicio rută (de exemplu, mountpoint sau mp), atunci punctul de export trebuie să fie și un punct de montare. Dacă nu este, atunci punctul de export nu este exportat. Acest lucru vă permite să vă asigurați că directorul de sub un punct de montare nu va fi niciodată exportat accidental dacă, de exemplu, sistemul de fișiere nu a reușit să se monteze din cauza unei erori de disc.

Dacă este furnizată o rută (de exemplu, mountpoint=/ruta sau mp=/ruta), atunci ruta nominalizată trebuie să fie un punct de montare pentru punctul de export care urmează să fie exportat.

NFS needs to be able to identify each filesystem that it exports. Normally it will use a UUID for the filesystem (if the filesystem has such a thing) or the device number of the device holding the filesystem (if the filesystem is stored on the device).

Deoarece nu toate sistemele de fișiere sunt stocate pe dispozitive și nu toate sistemele de fișiere au UUID-uri, uneori este necesar să se indice explicit lui NFS cum să identifice un sistem de fișiere. Acest lucru se face cu opțiunea fsid=.

Pentru NFSv4, există un sistem de fișiere distinct care este rădăcina tuturor sistemelor de fișiere exportate. Acesta este specificat cu fsid=root sau fsid=0, ambele însemnând exact același lucru.

Alte sisteme de fișiere pot fi identificate cu un mic număr întreg sau un UUID care ar trebui să conțină 32 de cifre hexazecimale și punctuație arbitrară.

Nucleele Linux versiunea 2.6.20 și anterioare nu înțeleg definiția UUID, astfel încât trebuie utilizat un număr întreg mic dacă o opțiune FSID trebuie să fie definită pentru astfel de nuclee. Se acceptă atât definirea unui număr mic, cât și a unui UUID, astfel încât aceeași configurație să poată funcționa atât pe nucleele vechi, cât și pe cele noi.

Această opțiune va dezactiva gestionarea cererilor READDIRPLUS. Atunci când este activată, cererile READDIRPLUS de la clienții NFS returnează NFS3ERR_NOTSUPP, iar clienții revin la READDIR. Această opțiune afectează numai clienții NFSv3.
Un client care face referire la punctul de export va fi direcționat să aleagă din lista dată o locație alternativă pentru sistemul de fișiere. (Rețineți că serverul trebuie să aibă un punct de montare aici, deși nu este necesar un sistem de fișiere diferit; astfel, de exemplu, mount --bind /ruta /ruta este suficient).

Această opțiune afectează numai clienții NFSv4. Alți clienți vor ignora toate părțile „refer=”.

Dacă clientul solicită locații alternative pentru punctul de export, i se va oferi această listă de alternative. (Rețineți că replicarea efectivă a sistemului de fișiere trebuie gestionată în altă parte).

Această opțiune permite utilizarea extensiei pNFS dacă nivelul protocolului este NFSv4.1 sau superior, iar sistemul de fișiere acceptă exporturile pNFS. Cu pNFS, clienții pot ocoli serverul și pot efectua operații de In/Ieș direct către dispozitivele de stocare. Valoarea implicită poate fi solicitată explicit cu opțiunea no_pnfs.

Cu această opțiune activată, clienții care utilizează NFSv4.2 sau o versiune mai recentă vor putea defini și prelua etichete de securitate (precum cele utilizate de SELinux). Acest lucru va funcționa numai dacă toți clienții utilizează o politică de securitate consecventă. Rețineți că primele nuclee nu acceptau această opțiune de export și, în schimb, activau etichetele de securitate în mod implicit.

Această opțiune ajută atunci când o partajare NFS este reexportată. Deoarece serverul NFS are nevoie de un identificator unic pentru fiecare sistem de fișiere exportat, iar o partajare NFS nu poate furniza un astfel de identificator, de obicei este necesar un fsid manual. De îndată ce crossmnt este utilizată, atribuirea manuală a fsid nu va mai funcționa. Acesta este momentul în care această opțiune devine utilă. Aceasta va atribui automat un fsid numeric partajărilor NFS exportate. Relațiile fsid și ruta sunt stocate într-o bază de date SQLite. Dacă se selectează auto-fsidnum, fsid-ul este, de asemenea, alocat automat. predefined-fsidnum presupune numere fsid prealocate și le va căuta pur și simplu. Această opțiune depinde și de nucleu, veți avea nevoie cel puțin de versiunea 5.19 a nucleului. Deoarece reexport= poate aloca și atribui automat fsids numerice, nu mai este posibil să aveți fsids numerice în alte exporturi de îndată ce această opțiune este utilizată în cel puțin o intrare de export.

Asocierea dintre numerele fsid și rute este stocată într-o bază de date SQLite. Nu editați sau eliminați baza de date decât dacă știți exact ce faceți.predefined-fsidnum este utilă atunci când ați folosit auto-fsidnum înainte și nu doriți să stocați alte intrări.

Corespondența ID-ului de utilizator

nfsd își bazează controlul accesului la fișierele de pe mașina server pe uid și gid furnizate în fiecare cerere NFS RPC. Comportamentul normal la care s-ar aștepta un utilizator este acela de a-și putea accesa fișierele de pe server la fel cum ar face-o pe un sistem de fișiere normal. Acest lucru necesită utilizarea acelorași uid și gid pe mașinile client și server. Acest lucru nu este întotdeauna adevărat și nici nu este întotdeauna de dorit.

De foarte multe ori, nu este de dorit ca utilizatorul root de pe o mașină client să fie tratat ca root și atunci când accesează fișiere de pe serverul NFS. În acest scop, uid 0 este în mod normal asociat cu un id diferit: așa-numitul uid anonim sau nobody. Acest mod de operare (numit „root squashing”) este implicit și poate fi dezactivat cu no_root_squash.

În mod implicit, exportfs alege un uid și un gid de 65534 pentru accesul squashed. Aceste valori pot fi, de asemenea, modificate prin opțiunile anonuid și anongid. În cele din urmă, puteți asocia toate cererile utilizatorilor cu uid-ul anonim specificând opțiunea all_squash.

Iată lista completă a opțiunilor de corespondență:

Asociază cererile de la uid/gid 0 la uid/gid anonim. Rețineți că acest lucru nu se aplică oricăror alte uid-uri sau gid-uri care ar putea fi la fel de sensibile, cum ar fi utilizatorul bin sau grupul staff.
Dezactivează asocierea cererilor de la uid/gid 0 la uid/gid anonim. Această opțiune este utilă în principal pentru clienții fără disc.
Asociază toate uid-urile și gid-urile cu utilizatorul anonim. Utilă pentru directoarele FTP publice exportate NFS, directoarele spool de știri etc. Opțiunea opusă este no_all_squash, care este opțiunea implicită.
Aceste opțiuni stabilesc în mod explicit uid-ul și gid-ul contului anonim. Această opțiune este utilă în primul rând pentru clienții PC/NFS, unde s-ar putea să doriți ca toate cererile să pară a fi de la un singur utilizator. Ca exemplu, luați în considerare intrarea de export pentru /home/joe din secțiunea de exemplu de mai jos, care asociază toate cererile cu uid 150 (care se presupune că este cel al utilizatorului joe).

Exporturi de subdirectoare

În mod normal, ar trebui să exportați doar rădăcina unui sistem de fișiere. Serverul NFS vă va permite, de asemenea, să exportați un subdirector al unui sistem de fișiere, însă acest lucru are dezavantaje:

În primul rând, poate fi posibil ca un utilizator rău intenționat să acceseze fișiere din sistemul de fișiere din afara subdirectorului exportat, prin ghicirea gestionarilor de fișiere pentru aceste alte fișiere. În unele cazuri, un utilizator rău intenționat poate, de asemenea, să acceseze fișiere de pe alte sisteme de fișiere care nu au fost exportate prin înlocuirea subdirectorului exportat cu o legătură simbolică către orice alt director. Singurul mod de a preveni acest lucru este prin utilizarea opțiunii subtree_check, care poate cauza alte probleme.

În al doilea rând, este posibil ca opțiunile de export să nu fie puse în aplicare în modul în care v-ați aștepta. De exemplu, opțiunea security_label nu va funcționa la exporturile de subdirectoare, iar dacă exporturile de subdirectoare imbricate modifică opțiunile security_label sau sec=, clienții NFSv4 vor vedea în mod normal numai opțiunile de pe exportul părinte. De asemenea, atunci când opțiunile de securitate diferă, un client rău intenționat poate utiliza atacuri de tip „filehandle-guessing” pentru a accesa fișierele dintr-un subdirector, utilizând opțiunile din altul.

Tabele de export suplimentare

După citirea fișierului /etc/exports exportfs citește fișierele din directorul /etc/exports.d ca tabele de export suplimentare. Sunt luate în considerare numai fișierele care se termină în .exports. Fișierele care încep cu un punct sunt ignorate. Formatul pentru tabelele de export suplimentare este același ca în cazul fișierului /etc/exports

EXEMPLU

# fișier „/etc/exports” de exemplu
/               master(rw) trusty(rw,no_root_squash)
/projects       proj*.local.domain(rw)
/usr            *.local.domain(ro) @trusted(rw)
/home/joe       pc001(rw,all_squash,anonuid=150,anongid=100)
/pub            *(ro,insecure,all_squash)
/srv/www        -sync,rw server @trusted @external(ro)
/foo            2001:db8:9:e54::/64(rw) 192.0.2.0/24(rw)
/build          buildhost[0-9].local.domain(rw)

Prima linie exportă întregul sistem de fișiere către mașinile master și trusty. În plus față de accesul la scriere, pentru gazda trusty se dezactivează toate operațiile de asociere a cererilor de la uid/gid 0 la uid/gid anonim A doua și a treia intrare prezintă exemple de nume de gazdă și grupuri de rețele cu caractere joker (aceasta este intrarea „@trusted”). A patra linie prezintă intrarea pentru clientul PC/NFS discutat mai sus. Linia 5 exportă directorul FTP public către toate gazdele din lume, executând toate cererile sub contul nobody. Opțiunea insecure din această intrare permite, de asemenea, accesul clienților cu implementări NFS care nu utilizează un port rezervat pentru NFS. A șasea linie exportă un director în citire-scriere către mașina „server”, precum și către grupul de rețea „@trusted” și numai în citire către grupul de rețea „@external”, toate cele trei montări având activată opțiunea „sync”. A șaptea linie exportă un director atât către o subrețea IPv6, cât și către o subrețea IPv4. A opta linie demonstrează o potrivire a unui caracter joker de clasă.

FIȘIERE

/etc/exports /etc/exports.d

CONSULTAȚI ȘI

exportfs(8), netgroup(5), mountd(8), nfsd(8), showmount(8), tlshd(8).

TRADUCERE

Traducerea în limba română a acestui manual a fost făcută de Remus-Gabriel Chelu <remusgabriel.chelu@disroot.org>

Această traducere este documentație gratuită; citiți Licența publică generală GNU Versiunea 3 sau o versiune ulterioară cu privire la condiții privind drepturile de autor. NU se asumă NICIO RESPONSABILITATE.

Dacă găsiți erori în traducerea acestui manual, vă rugăm să trimiteți un e-mail la translation-team-ro@lists.sourceforge.net.

31 decembrie 2009