Firewalld blocks access despite service added

Ask Fedora
, , , ,
1

I am generally quite accustomed to how firewalld works and have created several successful setups in the past. However, currently I am puzzled as to why it blocks traffic despite having added the service to the list.

What I am trying to establish is to share an NFS export with my other computer. I set up the export, enabled (and started) the nfs-server.service as well as added a firewalld service. SELinux I generally have set to permissive (please do not complain about it as it is besides this question).

Firewall configuration for my default zone looks as follows:

FedoraWorkstation (default, active)
  target: default
  ingress-priority: 0
  egress-priority: 0
  icmp-block-inversion: no
  interfaces: eno1 enp0s20f0u4u2c2
  sources: 
  services: dhcpv6-client nfs samba-client ssh
  ports: 1025-65535/udp 1025-65535/tcp
  protocols: 
  forward: yes
  masquerade: no
  forward-ports: 
  source-ports: 
  icmp-blocks: 
  rich rules:

I compared it with another computer I have set up NFS shares on (running Fedora 39) and it does not look (much) different (apart from it working there):

FedoraServer (default, active)
  target: default
  ingress-priority: 0
  egress-priority: 0
  icmp-block-inversion: no
  interfaces: eno1
  sources: 
  services: cockpit dhcp dhcpv6-client nfs samba ssh
  ports: 
  protocols: 
  forward: yes
  masquerade: no
  forward-ports: 
  source-ports: 
  icmp-blocks: 
  rich rules:

As soon as I stop firewalld, the port is open and I can access the share, but starting firewalld again, it immediately closes it again.

Is there anything I overlooked this time or is there a bug in the latest installment of firewalld on Fedora 40?

2

Removed selinux

3

Unprivileged NFS requires to allow some extra services:

sudo firewall-cmd --permanent --add-service=nfs
sudo firewall-cmd --permanent --add-service=mountd
sudo firewall-cmd --permanent --add-service=rpc-bind
sudo firewall-cmd --reload
2 Likes
4

Thank you! While mountd appeared to not be required, adding rpc-bind appeared to have solved the issue.

Could you also explain what you mean with ā€œunprivileged NFSā€, please? This would imply that there would also be a ā€œprivileged NFSā€ as opposite/alternative. What is the difference? How does one set up one or the other?

For example, on my server (the other computer running Fedora 39), all I did was setting up NFS like I tried today, but there it works ā€˜as isā€™ without having to add the rpc-bind service as well.

EDIT
Realized that the workstation has the ports 1025- open, which includes the port for mountd, thus not needing it in my particular setup on my workstation.

5

When NFS is mounted from fstab, it binds to a privileged port for historical reasons:
aws - Why is NFS client using low-numbered ports? - Unix & Linux Stack Exchange

File managers like Nautilus allow to mount NFS as unprivileged user without binding to privileged ports, but this requires to open extra ports on the server.

1 Like
6

Thanks for the explanation! Though I am still truly puzzled as all I was doing was setting up the NFS share (using Cockpit) and on the other side I configured autofs to mount it. It is the very same setup I have in reverse and worked for years without rpc-bind and mountd.

Anyway: Your first response solved this for me and I made a note on that for future reference to not forget (in case the Internet does).

1 Like