Puncte:0

Serverul NFS nu răspunde la cererea de montare nfs

drapel be

Am un server NFS care rulează pe un server Ubuntu pe hirsute care a încetat să mai răspundă la solicitările de montare după upgrade și nu pot rezolva de ce și o reinstalare nu a activat nfs-server-back. Se pare că serviciile auth-rpcgss-module și rpc-svcgssv nu rulează; nfs-config nu mai este activ, dar pare să-și fi finalizat sarcina și a ieșit. Aceste trei aveau puncte albe lângă ei în rezultatul comenzii list-dependencies; celelalte sunt verzi. și am încercat să reinstalez toate pachetele fără succes la pornirea serverului NFS. Am încercat să maschez ambele module, dar serverul nu pornește. Am pus chiar și tshark să asculte portul 2049, dar serverul nu arată nicio activitate, în timp ce clientul trimite pachetul TCP SYN la port fără răspuns. Serviciul nfs-server spune că a pornit și apoi a ieșit. Înnebunesc aici, cineva care poate ajuta la depanarea problemei?

Aceasta este rezultatul stării systemctl nfs-kernel-server:

$ sudo systemctl status nfs-kernel-server.service 
â nfs-server.service - server și servicii NFS
     Încărcat: încărcat (/lib/systemd/system/nfs-server.service; activat; prestabilit furnizor: ena>
    Drop-In: /run/systemd/generator/nfs-server.service.d
             ââcomandă-cu-monturi.conf
     Activ: activ (ieșit) din joi 2021-08-05 16:33:30 CEST; acum 8 minute
    Proces: 1655760 ExecStartPre=/usr/sbin/exportfs -r (cod=exit, status=0/SUCCESS)
    Proces: 1655761 ExecStart=/usr/sbin/rpc.nfsd $RPCNFSDARGS (code=exit, status=0/SU>
   PID principal: 1655761 (cod=ieșit, stare=0/SUCCESS)

05 august 16:33:29 calixto systemd[1]: Se pornește serverul și serviciile NFS...
Aug 05 16:33:30 calixto systemd[1]: Server și servicii NFS terminate.

Actualizat cu informații noi: am încercat să montez partajarea NFS de pe două mașini client Linux diferite, fără succes în niciuna dintre ele. Am adulmecat rețeaua cu tshark și se pare că TCP SYN nu ajunge la server, deoarece nu îl văd în fereastra tshark de pe server. Am încercat apoi să montez share-urile direct pe server și s-au montat fără probleme, așa că s-ar putea părea că există ceva în modul în care serverul kernel-ului nfs deschide portul 2049. Serverul are o punte între o interfață fizică de rețea și un unul virtual care servește un vm KVM și are și multe alte servicii care rulează (Apache, un server DLNa și mai multe) care funcționează fără probleme! Nu mai am sugestii despre cum să depanez această problemă, dar acum sunt sigur că este ceva legat de modul în care serverul nucleului NFW ascultă portul 2049... Vreo indicii?

SEWTGIYWTKHNTDS avatar
drapel cn
Există ceva în /etc/exports pentru ca sistemul să-l exporte? ce arată `journalctl -xe`
Ignacio Más avatar
drapel be
Da, /etc/exports conține directoarele de exportat. Uite ca vine: `/export 192.168.1.0/24(rw,sync) /export/Backup 192.168.1.3(rw,fsid=0,nesecure,no_subtree_check,async) /export/Media 192.168.1.0/24(ro,sync)`
Ignacio Más avatar
drapel be
journalctl nu arata nimic. De aceea cred că este legat de rețea. A Văd că sincronizarea TCP iese din client, dar nu ajunge la instanța tshark de pe server. Se pare că cumva sesiunea TCP nu este direcționată, dar toate celelalte servicii funcționează bine, inclusiv http, serverul DLNA, Mosquitto și multe altele
SEWTGIYWTKHNTDS avatar
drapel cn
Ufw rulează? ceva în ufw.log referitor la nfs sau accesul de la clienți?
Ignacio Más avatar
drapel be
Nu, nu am ufw instalat. Nici un alt firewall. Văd portul cu netstat atât pentru tc, cât și pentru tcp6 astfel: 'sudo netstat -n -p --tcp --listening | grep 2049 - tcp 0 0 0.0.0.0:2049 0.0.0.0:* ASCULTĂ - tcp6 0 0 :::2049 :::* ASCULTĂ -'
Ignacio Más avatar
drapel be
Este derutant că pot monta exporturile NFS de pe serverul însuși, conectându-se la IP-ul extern „192.168.1.2”, dar nu de pe orice altă mașină. Pur și simplu nu înțeleg unde sunt aruncate pachetele, deoarece toate celelalte servicii funcționează!
SEWTGIYWTKHNTDS avatar
drapel cn
Dacă rulați `nmap` împotriva sistemului de la una dintre mașinile client, ce porturi sunt deschise?
Ignacio Más avatar
drapel be
'nmap -P 192.168.1.2 Începând cu Nmap 7.80 ( https://nmap.org ) la 2021-08-05 21:07 CEST Raport de scanare Nmap pentru Calixto.MasFunke (192.168.1.2) Gazda este activă (latență de 0,00018s). Nu este afișat: 987 porturi închise SERVICIUL STATULUI PORTUAR 22/tcp deschide ssh 25/tcp deschide smtp 80/tcp deschide http 111/tcp deschide rpcbind 139/tcp deschide netbios-ssn 443/tcp deschide https 445/tcp deschide microsoft-ds 2049/tcp deschide nfs 8080/tcp deschide http-proxy 8086/tcp deschis d-s-n 8200/tcp deschide trivnet1 9090/tcp deschide zeus-admin 9099/tcp deschis necunoscut Adresă MAC: C8:1F:66:BC:F2:FE (Dell)”
Ignacio Más avatar
drapel be
2049 este deschis conform Nmap... deci trebuie să existe ceva în NFS-Kernelserver care să piardă pachetele... de ce? ma bate!
SEWTGIYWTKHNTDS avatar
drapel cn
Vă așteptați ca toate celelalte porturi să fie deschise pe serverul nfs? Am crezut că Vm-ul rula acele servicii. ce arată o scanare a adresei IP a VM? Asta oferă indicii? Dacă nmap vede porturile deschise, cred că pachetele trec. deoarece le puteți monta local, atunci sunt și eu nedumerit!
SEWTGIYWTKHNTDS avatar
drapel cn
Am întâlnit odată o problemă în care un comutator a fost confuz cu privire la locul unde ar trebui să trimită pachetele, dar cred că toate pachetele lipseau, nu am putut ping serverul de pe alte servere, dar puteți :(. Rezultatele dvs. din toate testele dvs. se potrivesc serverele mele ies și funcționează. Singura diferență pe care o văd este în permisiunile fișierelor de export, am `/home/git 192.168.57.0/24(rw,sync,no_root_squash,no_all_squash)`, poate că ceva s-a schimbat în securitatea serverul nfs care vă oprește conexiunile, aș fi crezut totuși că syslog ar arăta ceva
Ignacio Más avatar
drapel be
Folosesc VM-ul doar pentru o instalare a asistentului acasă. Adresa IP de pe VM (.38) care partajează puntea virtuală cu interfața fizică oferă doar două porturi deschise (22, ssh și 8082 Home assistant). Am o altă interfață în server (.37) pe un alt NIC fizic și scanarea Nmap pe acea interfață oferă *aceleași* porturi deschise ca și interfața cu punte, inclusiv portul NFS. Am încercat să montez pe acea interfață, dar tot nu am răspuns. Ei bine, mulțumesc pentru timpul acordat în orice caz! Voi continua să încerc lucruri și dacă am venit cu răspunsul îl voi posta și eu...
Ignacio Más avatar
drapel be
Înclin să mă gândesc și la opțiunile de scuritate...Acolo voi testa altele diferite
SEWTGIYWTKHNTDS avatar
drapel cn
Succes, sper să rezolvi în curând. Observ că aveți două rute către rețeaua dvs. pe serverul nfs, mă întreb dacă aceasta este problema, pachetele s-ar putea întoarce de la un alt IP (server nfs) decât la care au fost trimise. De ce să nu cobori interfața bridge de pe serverul nfs și să vezi dacă asta face vreo diferență.
Ignacio Más avatar
drapel be
Adăugând mai multe informații: am testat să fac un tcptracerote la portul 2049 care răspunde la TCP SYN cu un [SYN,ACK] adecvat și chiar am testat telneting de la mașina client la portul 2049 de pe server, care, de asemenea, răspunde cu un Stabilirea TCP. rularea tshark atât în ​​client, cât și în server arată TCP SYN + server SYN/ACK adecvat atât pentru cazul tcptraceroute, cât și pentru cazul telnet (care arată că rutarea IP funcționează corect), dar în cazul utilizării comenzii mount în client văd TCP SYN de la client dar nu vad *nimic* pe server!!! Poate fi o problemă cu montarea pe client?!?!
SEWTGIYWTKHNTDS avatar
drapel cn
Acest lucru nu are sens, dacă puteți telnet la port și pachetele ajung la server, dar comanda mount trimite aceleași pachete syn la același server și ele nu ajung. Din interes, care este comanda mount pe care o utilizați?
Ignacio Más avatar
drapel be
Știu! Nu avea sens, dar acum am reușit să izolez problema. Da, era legat de rețea și din cauza celor două interfețe de pe aceeași subrețea.Am pus jos a doua interfață de repornit comutatorul și acum am montat partajarea NFS fără probleme. Mă bate totuși de ce a funcționat telnet la port și celelalte servicii, dar, în orice caz, atunci când am doar interfețele cu punte (server + KVM VM) într-un singur port eth fizic, funcționează. Cred că trebuie să îmi reîmprospătesc cunoștințele despre protocoalele L2. :-) a existat în mod clar o buclă L2 care încurca protocolul NFs. Multumesc pentru tot ajutorul!
SEWTGIYWTKHNTDS avatar
drapel cn
Mă bucur să aud că ai rezolvat-o

Postează un răspuns

Majoritatea oamenilor nu înțeleg că a pune multe întrebări deblochează învățarea și îmbunătățește legătura interpersonală. În studiile lui Alison, de exemplu, deși oamenii își puteau aminti cu exactitate câte întrebări au fost puse în conversațiile lor, ei nu au intuit legătura dintre întrebări și apreciere. În patru studii, în care participanții au fost implicați în conversații ei înșiși sau au citit transcrieri ale conversațiilor altora, oamenii au avut tendința să nu realizeze că întrebarea ar influența – sau ar fi influențat – nivelul de prietenie dintre conversatori.