Rulez două servere nfs cu directoare de acasă ale utilizatorilor și alte partajări pe ele. Serverele oferă monturi kerberizate nfsv4, precum și cele vechi v3.
Până de curând am putut să montez nfs4 o partajare exportată cu krb5
de la un server pe al doilea fără probleme. Daca incerc acum
Primesc o permisiune refuzată și în jurnalul serverului nfs văd întotdeauna această eroare afișată mai jos. Sistemele de fișiere cu userdata de pe serverele nfs sunt situate în /export/user1 pe serverul gazdă1.uni-ko.de și /export/user2 pe serverul gazdă2.uni-ko.de (numele de gazdă au fost schimbate).
Calea /export/ este folosită ca rădăcină comună de export nfs4 marcată cu fsid=0.
## rulează pe serverul gazdă1.uni-ko.de
# mount -t nfs4 -o sec=krb5 server2.uni-ko.de:/user2 /mnt
mount.nfs4: acces refuzat de server în timpul instalării server2.uni-ko.de:/user2
iar în jurnalul serverelor nfs văd această eroare:
a refuzat cererea de montare de la server1.uni-ko.de pentru /user2 (/): nu a fost exportat
Același lucru se întâmplă dacă încerc să montez local o partajare pe aceeași gazdă
prin nfs4 astfel:
## pe serverul gazdă1.uni-ko.de
# mount -t nfs4 -o sec=krb5 server1.uni-ko.de:/user1 /mnt
mount.nfs4: acces refuzat de server în timpul instalării server1.uni-ko.de:/user1
O montare nfs3 (mount server1.uni-ko.de:/export/user1 /mnt) este posibilă fără probleme.
Fișierul /etc/exports de pe serverul gazdă2.uni-ko.de arată astfel:
/export gss/krb5(rw,fsid=0,nohide,no_subtree_check,no_root_squash,async,crossmnt) \
gss/krb5i(rw,fsid=0,nohide,no_subtree_check,no_root_squash,async,crossmnt) \
gss/krb5p(rw,fsid=0,nohide,no_subtree_check,no_root_squash,async,crossmnt)
# NFS V3 exportă prin grupuri de rețe NIS
/export/user2 @nfsv3client(rw,async,no_subtree_check,no_subtree_check,fsid=2000)
exportfs -v arată că acțiunile sunt (krb5-nfs4) exportate:
# exportfs -v
....
/export gss/krb5(rw,async,wdelay,nohide,crossmnt,no_subtree_check,fsid=0,sec=sys,secure,no_root_squash,no_all_squash)
/export gss/krb5i(rw,async,wdelay,nohide,crossmnt,no_subtree_check,fsid=0,sec=sys,secure,no_root_squash,no_all_squash)
/export gss/krb5p(rw,async,wdelay,nohide,crossmnt,no_subtree_check,fsid=0,sec=sys,secure,no_root_squash,no_all_squash)
/export/user2 @nfsv3client(rw,async,wdelay,hide,no_subtree_check,fsid=2000,sec=sys,secure,root_squash,no_all_squash)
Lucrurile devin și mai ciudate, deoarece de la un client nfs4 implicit, încă pot monta nfs4 directorul dat fără probleme exact așa cum este descris mai sus și ambele sisteme au același sistem de operare în aceeași versiune și nivel de patch care este SuSE SLES15SP3 cu cel mai recent patch-uri instalate.
Pe serverele nfs există un firewall care rulează care deschide porturile alocate static necesare pentru NFS, cum ar fi mountd,statd,lockd, precum și porturile 111 și 2049 (toate deschise pentru tcp și udp). Asta am schimbat recent. Înainte de această schimbare, porturile serverului nfs nu erau statice, ci setate implicit, dar nu pot vedea cum ar putea duce acest lucru la comportamentul ciudat de montare descris. De asemenea, am dezactivat complet firewall-ul și am testat din nou cu același rezultat.
În culise există un server Kerberos care rulează păstrând toate principiile necesare. Pentru serverele nfs și toți clienții nfs4 există principalele „nfs” și „gazdă” disponibile și fiecare server și client are un /etc/krb5.keytab care conține principalul „nfs” și „gazdă” exportat pentru această gazdă. Desigur, principiile utilizatorilor sunt stocate și în serverul Kerberos. Toate acestea au funcționat impecabil ani de zile și încă funcționează, cu excepția problemei descrise, care este nouă.
