To jsem takhle jednoho dne pustil počítač, šel na svazek připojený ze serveru… a nikam nedošel, protože svazek se v GUI tvářil šedivě a nedostupně. Pokus znovu ho připojit z commandline vyhodil access denied by server while mounting a bylo po legraci.

Podrobnější výpis z mountu

Nejprve jsem zjistil, jak zapnout trochu ukecanější mount:

mount -vvv -all

Výsledek sice byl podrobnější, ale ne o moc:

mount.nfs: timeout set for Sun Oct 13 23:15:53 2019
mount.nfs: trying text-based options 'retrans=6,timeo=200,vers=4.2, addr=xxx.xxx.xxx.xxx, clientaddr=yyy.yyy.yyy.yyy'
mount.nfs: mount(2): Permission denied
mount.nfs: trying text-based options 'retrans=6,timeo=200,vers=4,minorversion=1, addr=xxx.xxx.xxx.xxx, clientaddr=yyy.yyy.yyy.yyy'
mount.nfs: mount(2): Permission denied
mount.nfs: trying text-based options 'retrans=6,timeo=200,vers=4, addr=xxx.xxx.xxx.xxx, clientaddr=yyy.yyy.yyy.yyy'
mount.nfs: mount(2): Permission denied
mount.nfs: trying text-based options 'retrans=6,timeo=200,addr=xxx.xxx.xxx.xxx'
mount.nfs: prog 100003, trying vers=3, prot=6
mount.nfs: portmap query failed: RPC: Remote system error - No route to host
mount.nfs: access denied by server while mounting xxx.xxx.xxx.xxx:/mnt/data1


Permission denied, access denied… No paráda.

Zkusil jsem si tedy vygooglit nějaké rady; u RedHatu se tvářili, že je to časté a ukázali, co s tím:

Nastavit insecure export?

Do exportovaných adreářů na severu se má přidat klíčové slovo „insecure“.

(rw,all_squash,sync,no_subtree_check,insecure)

Mimochodem pozor na mezeru za čárkou, když ji tam přidáte:

(rw,all_squash,sync,no_subtree_check, insecure)

nebude tomu daemon rozumět a napíše, že je chybná syntaxe.

Provést reload pomocí

exportfs -rav

A jít přezkoušet. mount -all a nic. Falešná stopa.

Vrátil jsem se tedy k firewallům a prostupům, to bývá obvyklá kratochvíle.

Firewall?

Vyzbrojen informacemi z webu jsem si na serveru vypsal porty od mountd

rpcinfo -p

100005 1 udp 20048 mountd
100005 1 tcp 20048 mountd
100005 2 udp 20048 mountd
100005 2 tcp 20048 mountd
100005 3 udp 20048 mountd
100005 3 tcp 20048 mountd
100003 3 tcp 2049 nfs


Zkusil se připojit:

[root@client ~]#telnet xxx.xxx.xxx.xxx 20048
Trying xxx.xxx.xxx.xxx...
telnet: connect to address xxx.xxx.xxx.xxx: No route to host

Byl zaskočen, že není route; zkusil tedy povolit TCP:

firewall-cmd --add-port=20048/tcp --permanent

Zase nic, tak i UDP:

firewall-cmd --add-port=20048/udp --permanent

Pořád marné, tak na chvíli vypnout na serveru firewall úplně:

systemctl stop firewall

A TAKY NIC! Kompletně falešná stopa.

(Aby taky ne, pokud by tohle byl problém, tak asi nad portem od NFS, předpokládám.)

Pak jsem soustředil pozornost na logy…

Logy NFS daemona na serveru

Nejdřív jsem zjistil, že v messages není nic, pak vygooglil jak zapnout debug:

[root@server etc]# rpcdebug -m nfsd all
nfsd sock fh export svc proc fileop auth repcache xdr lockd
[root@server etc]# tail /var/log/messages

Ale že by to nějak významně pomohlo… Jak jsem ale věci dělal paralelně a v jednu chvíli jsem měl na serveru vypnutý firewall, zřejmě kromě NFS4 došlo i k pokusu o použití NFS3 a pro něj byla debug hláška trochu sdílnější:

Oct 13 23:52:05 server rpc.mountd[9951]: refused mount request from xxx.xxx.xxx.xxx for /mnt/data1 (/mnt/data1): unmatched host

Takže vypnout debug:

rpcdebug -m nfsd -c

A začít googlit unmatched host.

Oprava povolených IP u exportovaných systémů

Host… experimentálně jsem u jednoho záznamu místo hvězdičky napsal celou IP klientského počítače

[root@server ~]# exportfs -rav
exporting xxx.xxx.xxx.xxx:/mnt/data1
exporting xxx.xxx.xxx.*:/mnt/data2

A opravdu! Předtím přestala fungovat hvězdička. Rychlá kontrola dokumentace ukázala, že tam má být maska sítě!

/mnt/data1 xxx.xxx.xxx.0/24 (rw,all_squash,sync,no_subtree_check)

Ještě reload

exportfs -rav

A konečně jsem se na ten disk dostal. Ale už bylo tak pozdě, že už jsem tam vlastně ani nechtěl…

Celou anabázi si vysvětluji tak, že v exportu musela být nějaká chyba, která omylem akceptovala i hvězdičku, a teď ji opravili.