On 25/11/2020 05:43, Richard Kimberly Heck wrote:
On 11/24/20 2:12 PM, Jonathan Billings wrote:
> On Tue, Nov 24, 2020 at 02:06:46PM -0500, Richard Kimberly Heck wrote:
>> This looks like the issue:
>>
>> Nov 22 23:10:03 rkhstudy kernel: lockd: server 192.168.1.2 not responding,
>> still trying
>>
>> This was working fine in Fedora 32, though, so I'm puzzled what's wrong
now.
>> There's no firewall on the client, and nothing has changed on the server,
>> and I do not see any error messages there. Is lockd perhaps using a
>> different port, which is blocked on the server? If so, how do I find out
>> what that is?
> 'rpcinfo -p' should tell you port numbers, although it's usually
> something in the firewall that causes the issue.
Yes, thank you, that is definitely the problem. Disabling the firewall on the server
solves it. (Disabling the firewall on the client has no effect.) But of course that's
not a long-term solution, and I'm still puzzled why this is failing after the upgrade
but was working before.... I found a few relevant pages on the web, but they tell me to
enable services in the firewall that are already enabled.
Here's the firewall on the server:
# firewall-cmd --list-all
public (active)
target: default
icmp-block-inversion: no
interfaces: enp2s0
sources:
services: dhcpv6-client mountd nfs rpc-bind ssh
ports: 9000/tcp 9000/udp 3483/tcp 3483/udp 9090/tcp 9090/udp 1900/tcp 1900/udp
protocols:
masquerade: no
forward-ports:
source-ports:
icmp-blocks:
rich rules:
I restarted it in case something was wonky. No effect.
If you are using nfs-V3 you need to enable the nfs3 service in the active zone.
I haven't used nfs-V3 in a long time. However, I seem to remember that if you allow
nfs3 in
the services there is no need to define open ports as that is taken care of.
---
The key to getting good answers is to ask good questions.