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 lista de op<?>iuni
       <?>i o lista de control al accesului. Tabelul este utilizat de
       exportfs(8) pentru a furniza informa<?>ii catre mountd(8).

       Formatul fi<?>ierului este similar cu cel al fi<?>ierului exportsal
       SunOS. Fiecare linie con<?>ine un punct de export <?>i o lista separata
       prin spa<?>ii albe a clien<?>ilor carora li se permite sa monteze
       sistemul de fi<?>iere la acel punct. Fiecare client enumerat poate fi
       urmat imediat de o lista de op<?>iuni de export pentru clientul
       respectiv, separate prin virgule <?>i puse intre paranteze. Nu sunt
       permise spa<?>ii albe intre un client <?>i lista sa de op<?>iuni.

       De asemenea, fiecare linie poate avea una sau mai multe specifica<?>ii
       pentru op<?>iuni implicite dupa numele rutei, sub forma unei liniu<?>e
       (,,-") urmata de o lista de op<?>iuni. Lista de op<?>iuni este
       utilizata numai pentru toate exporturile ulterioare pe linia
       respectiva.

       Liniile goale sunt ignorate. Semnul lirei (,,#") introduce un
       comentariu la sfar<?>itul liniei. Inregistrarile pot fi continuate pe
       linii noi folosind o bara oblica inversa. Daca un nume de export
       con<?>ine spa<?>ii, acesta trebuie sa fie pus intre ghilimele duble. De
       asemenea, pute<?>i specifica spa<?>ii sau alte caractere neobi<?>nuite
       in numele de export folosind o bara oblica inversa urmata de codul
       caracterului sub forma a trei cifre octale.

       Pentru a aplica modificarile 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 in mai multe moduri:

       single host - (o singura gazda)
              Pute<?>i specifica o gazda fie printr-un nume abreviat
              recunoscut de rezolvator, fie printr-un nume de domeniu complet
              calificat, o adresa IPv4 sau o adresa IPv6. Adresele IPv6 nu
              trebuie sa se afle intre paranteze drepte in ,,/etc/exports"
              pentru a nu fi confundate cu potriviri de caractere de tip
              joker.

       IP networks - (re<?>ele IP)
              De asemenea, pute<?>i exporta simultan directoare catre toate
              gazdele dintr-o (sub)re<?>ea IP. Acest lucru se realizeaza prin
              specificarea unei adrese IP <?>i a unei perechi de ma<?>ti de
              re<?>ea ca adresa/masca de re<?>ea, unde masca de re<?>ea poate
              fi specificata in format zecimal punctat sau ca o lungime de
              masca contigua. De exemplu, fie ,,/255.255.252.0", fie ,,/22"
              adaugate la adresa IPv4 de baza a re<?>elei rezulta subre<?>ele
              identice cu 10 bi<?>i de gazda. Adresele IPv6 trebuie sa
              utilizeze o lungime de masca contigua <?>i nu trebuie sa se afle
              intre paranteze drepte pentru a evita confuzia cu caracterele
              joker de clasa. Caracterele joker nu func<?>ioneaza in general
              cu adresele IP, de<?>i pot func<?>iona accidental atunci cand
              cautarile DNS inverse e<?>ueaza.

       wildcards - (caractere joker)
              Numele ma<?>inilor pot con<?>ine caracterele joker * <?>i ? sau
              pot con<?>ine liste de clase de caractere intre [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.

       netgroups - (grupuri de re<?>ea)
              Grupurile de re<?>ea NIS pot fi date ca @group.  Numai partea de
              gazda a fiecarui membru al grupului de re<?>ea este luata in
              considerare pentru verificarea apartenen<?>ei. Par<?>ile de
              gazda goale sau cele care con<?>in o singura liniu<?>a (-) sunt
              ignorate.

       anonymous - (anonim)
              Aceasta este specificata printr-un singur caracter * (a nu se
              confunda cu caractere joker de mai sus) <?>i se va potrivi
              tuturor clien<?>ilor.

       Daca un client corespunde mai multor specifica<?>ii de mai sus, prima
       potrivire din lista de mai sus are prioritate - indiferent de ordinea
       in care apar in linia de export. Cu toate acestea, in cazul in care un
       client corespunde mai multor specifica<?>ii de acela<?>i tip (de
       exemplu, doua grupuri de re<?>ele), atunci are prioritate prima
       potrivire din ordinea in 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
       utilizeaza securitatea rpcsec_gss. Cu toate acestea, aceasta sintaxa
       este depreciata; pe nucleele linux incepand cu versiunea 2.6.23, ar
       trebui sa utiliza<?>i in schimb op<?>iunea de export ,,sec=":

       sec=   Op<?>iunea sec=, urmata de o lista de tipuri de securitate
              delimitata prin doua puncte, restric<?>ioneaza exportul la
              clien<?>ii care utilizeaza respectivele tipuri. Tipurile de
              securitate disponibile includ sys (implicit - nicio securitate
              criptografica), krb5 (doar autentificare), krb5i (protec<?>ie a
              integrita<?>ii) <?>i krb5p (protec<?>ie a
              confiden<?>ialita<?>ii). In scopul negocierii variantelor de
              securitate, ordinea conteaza: variantele preferate ar trebui sa
              fie enumerate primele. Ordinea op<?>iunii sec= in raport cu
              celelalte op<?>iuni nu conteaza, cu excep<?>ia cazului in care
              dori<?>i ca anumite op<?>iuni sa fie aplicate in mod diferit in
              func<?>ie de varianta de securitate. In acest caz, pute<?>i
              include mai multe op<?>iuni sec=, iar urmatoarele op<?>iuni vor
              fi puse in aplicare numai pentru accesul care utilizeaza
              variantele enumerate in op<?>iunea sec= imediat anterioara.
              Singurele op<?>iuni care pot varia in 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 intre el <?>i clien<?>ii sai. Alternativ,
       administratorii pot securiza traficul NFS utilizand un VPN, un tunel
       ssh sau un mecanism similar, intr-un mod transparent pentru server.

       Pentru a permite utilizarea RPC-cu-TLS, administratorul serverului
       trebuie sa instaleze <?>i sa configureze tlshd pentru a gestiona
       cererile de negociere privind securitatea stratului de transport de la
       nucleul local.  Clien<?>ii pot alege apoi sa utilizeze RPC-cu-TLS sau
       pot continua sa func<?>ioneze fara aceasta.

       Administratorii pot solicita utilizarea RPC-cu-TLS pentru a proteja
       accesul la exporturi individuale. Acest lucru este deosebit de util
       atunci cand se utilizeaza variante de securitate necriptografice, cum
       ar fi sec=sys. Op<?>iunea xprtsec=, urmata de o lista neordonata
       delimitata de doua 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 in prezent includ:

       none   Serverul permite clien<?>ilor sa acceseze exportul fara a
              utiliza securitatea stratului de transport.

       tls    Serverul permite clien<?>ilor care au negociat o sesiune
              RPC-cu-TLS fara autentificare ,,peer" (numai
              confiden<?>ialitate) sa acceseze exportul. Clien<?>ii nu sunt
              obliga<?>i sa ofere un certificat x.509 atunci cand stabilesc o
              sesiune de securitate a stratului de transport.

       mtls   Serverul permite clien<?>ilor care au negociat o sesiune
              RPC-cu-TLS cu autentificare ,,peer"sa acceseze exportul.
              Serverul solicita clien<?>ilor sa ofere un certificat x.509
              atunci cand stabilesc o sesiune de securitate a stratului de
              transport.

       Daca RPC-cu-TLS este configurat <?>i activat <?>i op<?>iunea xprtsec=
       nu este specificata, valoarea implicita pentru un export este
       xprtsec=none:tls:mtls.  Cu aceasta defini<?>ie, serverul permite
       clien<?>ilor sa utilizeze orice mecanism de securitate a stratului de
       transport sau niciunul pentru a accesa exportul.

   Op<?>iuni generale
       exportfs in<?>elege urmatoarele op<?>iuni de export:

       secure Aceasta op<?>iune impune ca cererile care nu utilizeaza gss sa
              provina de pe un port Internet mai mic decat IPPORT_RESERVED
              (1024). Aceasta op<?>iune este activata in mod implicit. Pentru
              a o dezactiva, specifica<?>i insecure.  (NOTA: nucleele mai
              vechi (inainte de versiunea 4.17 a nucleului din amonte)
              impuneau aceasta cerin<?>a <?>i pentru cererile gss).

       rw     Permite atat cererile de citire, cat <?>i cele de scriere pe
              acest volum NFS. Valoarea implicita este de a nu permite nicio
              cerere care modifica sistemul de fi<?>iere. Acest lucru poate
              fi, de asemenea, facut explicit prin utilizarea op<?>iunii ro.

       async  Aceasta op<?>iune permite serverului NFS sa incalce protocolul
              NFS <?>i sa raspunda la solicitari inainte ca orice modificari
              aduse de solicitarea respectiva sa fi fost inregistrate in
              stocarea stabila (de exemplu, unitatea de disc).

              Utilizarea acestei op<?>iuni imbunata<?>e<?>te de obicei
              performan<?>a, dar cu pre<?>ul ca o repornire necura<?>ata a
              serverului (de exemplu, o prabu<?>ire) poate cauza pierderea sau
              deteriorarea datelor.


       sync   Raspunde la solicitari numai dupa ce modificarile au fost
              introduse in stocarea stabila (a se vedea async de mai sus).

              In versiunile de nfs-utils pana la 1.0.0 inclusiv, op<?>iunea
              async a fost cea implicita. In toate versiunile dupa 1.0.0, sync
              este op<?>iunea implicita, iar async trebuie solicitata explicit
              daca este necesar.

       no_wdelay
              Aceasta op<?>iune nu are niciun efect daca async este de
              asemenea definita. Serverul NFS va intarzia in mod normal cu
              pu<?>in comiterea unei cereri de scriere pe disc daca
              suspecteaza ca o alta cerere de scriere conexa poate fi in curs
              sau poate sosi in curand. Acest lucru permite transmiterea mai
              multor cereri de scriere pe disc cu o singura opera<?>ie, ceea
              ce poate imbunata<?>i performan<?>a. Daca un server NFS
              prime<?>te in principal cereri mici fara legatura, acest
              comportament ar putea reduce de fapt performan<?>a, astfel incat
              no_wdelay este disponibila pentru a o dezactiva. Valoarea
              implicita poate fi solicitata explicit cu op<?>iunea wdelay.

       nohide Aceasta op<?>iune se bazeaza pe op<?>iunea cu acela<?>i nume
              oferita in NFS IRIX. In mod normal, daca un server exporta doua
              sisteme de fi<?>iere, dintre care unul este montat pe celalalt,
              clientul va trebui sa monteze explicit ambele sisteme de
              fi<?>iere pentru a avea acces la ele. Daca monteaza doar
              parintele, va vedea un director gol in locul in care este montat
              celalalt sistem de fi<?>iere. Acest sistem de fi<?>iere este
              ,,ascuns".

              Definirea op<?>iunii nohide pe un sistem de fi<?>iere face ca
              acesta sa nu fie ascuns, iar un client autorizat corespunzator
              va putea sa treaca de la sistemul parinte la acel sistem de
              fi<?>iere fara sa observe schimbarea.

              Cu toate acestea, unii clien<?>i NFS nu se descurca bine cu
              aceasta situa<?>ie deoarece, de exemplu, este posibil ca doua
              fi<?>iere din acela<?>i sistem de fi<?>iere aparent sa aiba
              acela<?>i numar de nod-i.

              Op<?>iunea nohide este eficienta in prezent numai pentru
              exporturile catre o singura gazda. Aceasta nu func<?>ioneaza in
              mod fiabil cu exporturile catre grupuri de re<?>ea, sub-re<?>ea
              sau clien<?>i numi<?>i cu ajutorul caracterelor joker.

              Aceasta op<?>iune poate fi foarte utila in anumite situa<?>ii,
              dar trebuie utilizata cu aten<?>ia cuvenita <?>i numai dupa
              confirmarea faptului ca sistemul client face fa<?>a situa<?>iei
              in mod eficient.

              Op<?>iunea poate fi dezactivata explicit pentru NFSv2 <?>i NFSv3
              cu hide.

              Aceasta op<?>iune nu este relevanta atunci cand se utilizeaza
              NFSv4. NFSv4 nu ascunde niciodata sistemele de fi<?>iere
              subordonate. Orice sistem de fi<?>iere care este exportat va fi
              vizibil acolo unde este de a<?>teptat atunci cand se utilizeaza
              NFSv4.

       crossmnt
              Aceasta op<?>iune este similara cu nohide, dar permite
              clien<?>ilor sa acceseze toate sistemele de fi<?>iere montate pe
              un sistem de fi<?>iere marcat cu crossmnt.  Astfel, atunci cand
              un sistem de fi<?>iere copil ,,B" este montat pe un sistem
              parinte ,,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 sa fie exportat
              explicit. Cu crossmnt nu este necesar. Daca 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
              parintele, cu excep<?>ia fsid=. Acest lucru face imposibil sa nu
              se exporte un copil al unui sistem de fi<?>iere crossmnt. Daca
              unele, dar nu toate sistemele de fi<?>iere subordonate unui
              parinte trebuie sa fie exportate, atunci acestea trebuie sa fie
              exportate explicit, iar parintelui nu trebuie sa i se defineasca
              crossmnt.

              Op<?>iunea nocrossmnt poate dezactiva in mod explicit crossmnt
              daca a fost definita anterior. Acest lucru este rareori util.

       subtree_check
              Aceasta op<?>iune activeaza verificarea subarborelui, care poate
              avea u<?>oare beneficii de securitate, dar poate reduce
              fiabilitatea in anumite circumstan<?>e.

              Daca un subdirector dintr-un sistem de fi<?>iere este exportat,
              dar intregul sistem de fi<?>iere nu este, atunci de fiecare data
              cand sose<?>te o cerere NFS, serverul trebuie sa verifice nu
              numai daca fi<?>ierul accesat se afla in sistemul de fi<?>iere
              corespunzator (ceea ce este u<?>or), ci <?>i daca se afla in
              arborele exportat (ceea ce este mai greu). Aceasta verificare se
              nume<?>te subtree_check.

              Pentru a efectua aceasta verificare, serverul trebuie sa includa
              unele informa<?>ii despre loca<?>ia fi<?>ierului in
              ,,filehandle" care este dat clientului. Acest lucru poate cauza
              probleme la accesarea fi<?>ierelor care sunt redenumite in timp
              ce un client le are deschise (de<?>i in multe cazuri simple va
              func<?>iona in continuare).

              verificarea subarborelui este, de asemenea, utilizata pentru a
              se asigura ca fi<?>ierele din interiorul directoarelor la care
              doar root are acces pot fi accesate numai daca sistemul de
              fi<?>iere este exportat cu no_root_squash (a se vedea mai jos),
              chiar daca fi<?>ierul in 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 in mod normal exportat la radacina <?>i in
              care pot aparea multe redenumiri de fi<?>iere, ar trebui sa fie
              exportat cu verificarea sub-arborelui dezactivata. Un sistem de
              fi<?>iere care este in cea mai mare parte de tip numai-citire
              <?>i pentru care cel pu<?>in nu exista multe redenumiri de
              fi<?>iere (de exemplu, ,,/usr" sau ,,/var") <?>i pentru care
              subdirectoarele pot fi exportate, ar trebui probabil sa fie
              exportat cu verificarea sub-arborelui activata.

              Verificarile implicite ale subarborelui sunt dezactivate <?>i
              pot fi solicitate explicit cu no_subtree_check.

              Inainte de versiunea 1.1.0 a nfs-utils, valoarea implicita era
              subtree_check. De la versiunea 1.1.0, op<?>iunea implicita este
              no_subtree_check, deoarece verificarea subarborelui tinde sa
              cauzeze mai multe probleme decat merita. Daca ave<?>i
              intr-adevar nevoie de verificarea subarborelui, trebuie sa
              introduce<?>i explicit aceasta op<?>iune in fi<?>ierul exports.
              Daca nu introduce<?>i nicio op<?>iune, exportfs va va avertiza
              ca modificarea a avut loc.


       insecure_locks

       no_auth_nlm
              Aceasta op<?>iune (cele doua nume sunt sinonime) indica
              serverului NFS sa nu solicite autentificarea cererilor de
              blocare (adica cererile care utilizeaza protocolul NLM). In mod
              normal, serverul NFS va solicita ca o cerere de blocare sa
              de<?>ina o acreditare pentru un utilizator care are acces de
              citire la fi<?>ier. Cu aceasta op<?>iune nu se va efectua nicio
              verificare a accesului.

              Implementarile anterioare ale clien<?>ilor NFS nu trimiteau
              acreditari cu cererile de blocare <?>i exista inca mul<?>i
              clien<?>i NFS actuali care se bazeaza pe implementarile vechi.
              Utiliza<?>i acest fanion daca constata<?>i ca pute<?>i bloca
              numai fi<?>iere care pot fi citite de toata lumea.

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


       mountpoint=ruta

       mp     Aceasta op<?>iune face posibila exportarea unui director numai
              daca acesta a fost montat cu succes. Daca nu este indicata nicio
              ruta (de exemplu, mountpoint sau mp), atunci punctul de export
              trebuie sa fie <?>i un punct de montare. Daca nu este, atunci
              punctul de export nu este exportat. Acest lucru va permite sa va
              asigura<?>i ca directorul de sub un punct de montare nu va fi
              niciodata exportat accidental daca, de exemplu, sistemul de
              fi<?>iere nu a reu<?>it sa se monteze din cauza unei erori de
              disc.

              Daca este furnizata o ruta (de exemplu, mountpoint=/ruta sau
              mp=/ruta), atunci ruta nominalizata trebuie sa fie un punct de
              montare pentru punctul de export care urmeaza sa fie exportat.


       fsid=num|root|uuid
              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 sa se indice explicit lui NFS cum sa
              identifice un sistem de fi<?>iere.  Acest lucru se face cu
              op<?>iunea fsid=.

              Pentru NFSv4, exista un sistem de fi<?>iere distinct care este
              radacina tuturor sistemelor de fi<?>iere exportate. Acesta este
              specificat cu fsid=root sau fsid=0, ambele insemnand exact
              acela<?>i lucru.

              Alte sisteme de fi<?>iere pot fi identificate cu un mic numar
              intreg sau un UUID care ar trebui sa con<?>ina 32 de cifre
              hexazecimale <?>i punctua<?>ie arbitrara.

              Nucleele Linux versiunea 2.6.20 <?>i anterioare nu in<?>eleg
              defini<?>ia UUID, astfel incat trebuie utilizat un numar intreg
              mic daca o op<?>iune FSID trebuie sa fie definita pentru astfel
              de nuclee. Se accepta atat definirea unui numar mic, cat <?>i a
              unui UUID, astfel incat aceea<?>i configura<?>ie sa poata
              func<?>iona atat pe nucleele vechi, cat <?>i pe cele noi.


       nordirplus
              Aceasta op<?>iune va dezactiva gestionarea cererilor
              READDIRPLUS. Atunci cand este activata, cererile READDIRPLUS de
              la clien<?>ii NFS returneaza NFS3ERR_NOTSUPP, iar clien<?>ii
              revin la READDIR.  Aceasta op<?>iune afecteaza numai clien<?>ii
              NFSv3.

       refer=ruta@gazda[+gazda][:ruta@gazda[+gazda]]
              Un client care face referire la punctul de export va fi
              direc<?>ionat sa aleaga din lista data o loca<?>ie alternativa
              pentru sistemul de fi<?>iere. (Re<?>ine<?>i ca serverul trebuie
              sa aiba 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).

              Aceasta op<?>iune afecteaza numai clien<?>ii NFSv4. Al<?>i
              clien<?>i vor ignora toate par<?>ile ,,refer=".

       replicas=ruta@gazda[+gazda][:ruta@gazda[+gazda]]
              Daca clientul solicita loca<?>ii alternative pentru punctul de
              export, i se va oferi aceasta lista de alternative.
              (Re<?>ine<?>i ca replicarea efectiva a sistemului de fi<?>iere
              trebuie gestionata in alta parte).


       pnfs   Aceasta op<?>iune permite utilizarea extensiei pNFS daca nivelul
              protocolului este NFSv4.1 sau superior, iar sistemul de
              fi<?>iere accepta exporturile pNFS. Cu pNFS, clien<?>ii pot
              ocoli serverul <?>i pot efectua opera<?>ii de In/Ie<?> direct
              catre dispozitivele de stocare. Valoarea implicita poate fi
              solicitata explicit cu op<?>iunea no_pnfs.


       security_label
              Cu aceasta op<?>iune activata, clien<?>ii care utilizeaza
              NFSv4.2 sau o versiune mai recenta vor putea defini <?>i prelua
              etichete de securitate (precum cele utilizate de SELinux). Acest
              lucru va func<?>iona numai daca to<?>i clien<?>ii utilizeaza o
              politica de securitate consecventa. Re<?>ine<?>i ca primele
              nuclee nu acceptau aceasta op<?>iune de export <?>i, in schimb,
              activau etichetele de securitate in mod implicit.


       reexport=auto-fsidnum|predefined-fsidnum
              Aceasta op<?>iune ajuta atunci cand o partajare NFS este
              reexportata. 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 indata ce crossmnt
              este utilizata, atribuirea manuala a fsid nu va mai func<?>iona.
              Acesta este momentul in care aceasta op<?>iune devine utila.
              Aceasta va atribui automat un fsid numeric partajarilor NFS
              exportate. Rela<?>iile fsid <?>i ruta sunt stocate intr-o baza
              de date SQLite. Daca se selecteaza auto-fsidnum, fsid-ul este,
              de asemenea, alocat automat.  predefined-fsidnum presupune
              numere fsid prealocate <?>i le va cauta pur <?>i simplu.
              Aceasta 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
              sa ave<?>i fsids numerice in alte exporturi de indata ce aceasta
              op<?>iune este utilizata in cel pu<?>in o intrare de export.

              Asocierea dintre numerele fsid <?>i rute este stocata intr-o
              baza de date SQLite. Nu edita<?>i sau elimina<?>i baza de date
              decat daca <?>ti<?>i exact ce face<?>i.predefined-fsidnum este
              utila atunci cand a<?>i folosit auto-fsidnum inainte <?>i nu
              dori<?>i sa stoca<?>i alte intrari.



   Coresponden<?>a ID-ului de utilizator
       nfsd i<?>i bazeaza controlul accesului la fi<?>ierele de pe ma<?>ina
       server pe uid <?>i gid furnizate in 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 necesita utilizarea
       acelora<?>i uid <?>i gid pe ma<?>inile client <?>i server. Acest lucru
       nu este intotdeauna adevarat <?>i nici nu este intotdeauna de dorit.

       De foarte multe ori, nu este de dorit ca utilizatorul root de pe o
       ma<?>ina client sa fie tratat ca root <?>i atunci cand acceseaza
       fi<?>iere de pe serverul NFS. In acest scop, uid 0 este in 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.

       In 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. In cele din urma, pute<?>i asocia
       toate cererile utilizatorilor cu uid-ul anonim specificand op<?>iunea
       all_squash.

       Iata lista completa a op<?>iunilor de coresponden<?>a:

       root_squash
              Asociaza cererile de la uid/gid 0 la uid/gid anonim.
              Re<?>ine<?>i ca acest lucru nu se aplica oricaror alte uid-uri
              sau gid-uri care ar putea fi la fel de sensibile, cum ar fi
              utilizatorul bin sau grupul staff.

       no_root_squash
              Dezactiveaza asocierea cererilor de la uid/gid 0 la uid/gid
              anonim. Aceasta op<?>iune este utila in principal pentru
              clien<?>ii fara disc.

       all_squash
              Asociaza toate uid-urile <?>i gid-urile cu utilizatorul anonim.
              Utila pentru directoarele FTP publice exportate NFS,
              directoarele spool de <?>tiri etc. Op<?>iunea opusa este
              no_all_squash, care este op<?>iunea implicita.

       anonuid <?>i anongid
              Aceste op<?>iuni stabilesc in mod explicit uid-ul <?>i gid-ul
              contului anonim. Aceasta op<?>iune este utila in primul rand
              pentru clien<?>ii PC/NFS, unde s-ar putea sa dori<?>i ca toate
              cererile sa para a fi de la un singur utilizator. Ca exemplu,
              lua<?>i in considerare intrarea de export pentru /home/joe din
              sec<?>iunea de exemplu de mai jos, care asociaza toate cererile
              cu uid 150 (care se presupune ca este cel al utilizatorului
              joe).


   Exporturi de subdirectoare
       In mod normal, ar trebui sa exporta<?>i doar radacina unui sistem de
       fi<?>iere. Serverul NFS va va permite, de asemenea, sa exporta<?>i un
       subdirector al unui sistem de fi<?>iere, insa acest lucru are
       dezavantaje:

       In primul rand, poate fi posibil ca un utilizator rau inten<?>ionat sa
       acceseze fi<?>iere din sistemul de fi<?>iere din afara subdirectorului
       exportat, prin ghicirea gestionarilor de fi<?>iere pentru aceste alte
       fi<?>iere. In unele cazuri, un utilizator rau inten<?>ionat poate, de
       asemenea, sa acceseze fi<?>iere de pe alte sisteme de fi<?>iere care nu
       au fost exportate prin inlocuirea subdirectorului exportat cu o
       legatura simbolica catre orice alt director. Singurul mod de a preveni
       acest lucru este prin utilizarea op<?>iunii subtree_check, care poate
       cauza alte probleme.

       In al doilea rand, este posibil ca op<?>iunile de export sa nu fie puse
       in aplicare in modul in care v-a<?>i a<?>tepta. De exemplu, op<?>iunea
       security_label nu va func<?>iona la exporturile de subdirectoare, iar
       daca exporturile de subdirectoare imbricate modifica op<?>iunile
       security_label sau sec=, clien<?>ii NFSv4 vor vedea in mod normal numai
       op<?>iunile de pe exportul parinte. De asemenea, atunci cand
       op<?>iunile de securitate difera, un client rau inten<?>ionat poate
       utiliza atacuri de tip ,,filehandle-guessing" pentru a accesa
       fi<?>ierele dintr-un subdirector, utilizand op<?>iunile din altul.



   Tabele de export suplimentare
       Dupa citirea fi<?>ierului /etc/exports exportfs cite<?>te fi<?>ierele
       din directorul /etc/exports.d ca tabele de export suplimentare. Sunt
       luate in considerare numai fi<?>ierele care se termina in .exports.
       Fi<?>ierele care incep cu un punct sunt ignorate.  Formatul pentru
       tabelele de export suplimentare este acela<?>i ca in 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 exporta intregul sistem de fi<?>iere catre ma<?>inile
       master <?>i trusty. In plus fa<?>a de accesul la scriere, pentru gazda
       trusty se dezactiveaza toate opera<?>iile de asociere a cererilor de la
       uid/gid 0 la uid/gid anonim A doua <?>i a treia intrare prezinta
       exemple de nume de gazda <?>i grupuri de re<?>ele cu caractere joker
       (aceasta este intrarea ,,@trusted"). A patra linie prezinta intrarea
       pentru clientul PC/NFS discutat mai sus. Linia 5 exporta directorul FTP
       public catre toate gazdele din lume, executand toate cererile sub
       contul nobody. Op<?>iunea insecure din aceasta intrare permite, de
       asemenea, accesul clien<?>ilor cu implementari NFS care nu utilizeaza
       un port rezervat pentru NFS.  A <?>asea linie exporta un director in
       citire-scriere catre ma<?>ina ,,server", precum <?>i catre grupul de
       re<?>ea ,,@trusted" <?>i numai in citire catre grupul de re<?>ea
       ,,@external", toate cele trei montari avand activata op<?>iunea
       ,,sync". A <?>aptea linie exporta un director atat catre o subre<?>ea
       IPv6, cat <?>i catre o subre<?>ea IPv4. A opta linie demonstreaza o
       potrivire a unui caracter joker de clasa.

FI<?>IERE
       /etc/exports /etc/exports.d

CONSULTA<?>I <?>I
       exportfs(8), netgroup(5), mountd(8), nfsd(8), showmount(8), tlshd(8).

TRADUCERE
       Traducerea in limba romana a acestui manual a fost facuta de Remus-
       Gabriel Chelu <remusgabriel.chelu@disroot.org>

       Aceasta traducere este documenta<?>ie gratuita; citi<?>i Licen<?>a
       publica generala GNU Versiunea 3
       <https://www.gnu.org/licenses/gpl-3.0.html> sau o versiune ulterioara
       cu privire la condi<?>ii privind drepturile de autor.  NU se asuma
       NICIO RESPONSABILITATE.

       Daca gasi<?>i erori in traducerea acestui manual, va rugam sa
       trimite<?>i un e-mail la <translation-team-ro@lists.sourceforge.net>.

                               31 decembrie 2009                    exports(5)