I have a fresh install of Leap 15.1 (yesterday). Firewalld is configured upon install to allow access to the Internet, but I am unable to enable NFS shares for the machines on the the local network (all running 15.1). They were previously able to reach this machine (the server) when it was running Leap 42.3 and probably SuSEfirewall2.
The NFS server dialog provides the following message:
Firewall not configurable
Some firewalld services are not available:
- nfs-kernel-server (Not available)
These services must be defined in order to configure the firewall.
I have read the Firewalld documentation and third-party posts (e.g., Centos, Techmint, others), and tried to use the Firewall Configuration dialog (changed from Runtime to Permanent), but no success.
I suspect there are a few straightforward settings to open the interface to the network, but I am unable to determine what those are. The command line examples are clear enough, but I don’t know which apply to my case.
Here are the results of two queries:
linux-5:~ systemctl status firewalld
● firewalld.service - firewalld - dynamic firewall daemon
Loaded: loaded (/usr/lib/systemd/system/firewalld.service; enabled; vendor preset: d>
Active: active (running) since Fri 2020-01-03 07:02:48 EST; 4min 29s ago
Docs: man:firewalld(1)
Main PID: 15900 (firewalld)
Tasks: 2 (limit: 4915)
CGroup: /system.slice/firewalld.service
└─15900 /usr/bin/python3 -Es /usr/sbin/firewalld --nofork --nopid
Jan 03 07:02:48 linux-5.fios-router.home systemd[1]: Starting firewalld - dynamic firew>
Jan 03 07:02:48 linux-5.fios-router.home systemd[1]: Started firewalld - dynamic firewa>
I’d recommend you read and use the LEAP documentation before considering others (and in those cases might consider Fedora, then ArchWiki, then CentOS guides).
I’m confused by what you posted…
You said that you just installed a new machine to be used as an NFS client, yet you are posting output about the NFS Server firewall settings…
If your NFS shares are already working for other machines, you probably shouldn’t touch it beyond possibly modifying authentication credentials…
Easiest way to troubleshoot a problem you can invoke on demand is to
Open a separate console and use it to read your system log in real time. You’ll likely catch what is happening (including error) without having to search your system log for relevant events
To do this, run the following in your console/terminal
journalctl -f
In your case, you should be able to see the difference between your manual mount and invoking using your systemd Unit file.
In my original post, I neglected to mention the openSuSE manual, specifically section 22.3, and SuSE security guide, chap. 17, referenced in the former, which I read several times yesterday, as well as the Firewalld man page on zones (https://firewalld.org/documentation/man-pages/firewalld.zones.html). The various discussions about command line entries made sense but I couldn’t glean a specific suggestion or solution. I did notice the nfs entry in both interfaces (YaST and Firewall-Configuration).
I sent the screen shot of the Firewall-Config dialog before I saw your query about the YaST dialog. As far as I can tell, they both modify the config file.
Your suggestion of adding nfs solved the problem. Thank you.
But why the public zone? Wouldn’t I be better off in the home, trusted, or work zones? Unfortunately and this is what I found confusing, the SuSE documents and the Firewalld man pages do not appear to use similar terms in the same way (see, e.g., trusted). The Firewalld man page sets out the hierarchy of the various zones, and “public” doesn’t appear to be an obvious choice. Here, I have essentially two zones - the LAN which includes the firewall router, and the cable to the ISP. For now, I placed the nfs in the work zone (and removed it from the public zone).
Further, after re-reading the Firewalld documentation and other materials, I realized that the premise of my question concerning the relative safety of the various pre-configured zones was based on a misunderstanding of how the firewall operates. My guess is that the name of the operating zone is not the controlling factor. Rather, it is the enabled services, ports, etc. that determine what can pass. Another guess is that Firewalld is simply a rules-based device - it does not perform any function other than what the user instructs (by enabling services, ports, etc.). I don’t believe Firewalld performs a deep packet inspection or a similar function.
At least for now, my configuration of Firewalld is allowing the other Leap 15.1 machines to access the NFS shares on the “server” machine. In addition to adding nfs as suggested by Knurpht, I added mountd and rpc-bind. The other machines were then able to consistently access the NFS server shares. Although the documentation states that nfsv4 should work with nfs service alone, and all of the machines in the network confirmed by command line query that they were using nfsv4 for the client, nfs alone was not sufficient. Rather, I needed to add the services required for nfsv3 (i.e., mountd and rpc-bind).
Although the Windows 7 guest in Virtualbox was able to reach the network printer, it then appeared that the printer was not reachable by the (host) Linux machine (using, of course, CUPS). After adding ipp, ipp-client, and mdns services to the operating zone, the printer was reachable. (ipp-client may not be required, but I haven’t tested the firewall without that service and the printer uses bidirectional communication for some functions.)
The appearance of the Firewalld page in Yast has changed. The documentation and links in this message thread whow what it used to me. I now see https://susepaste.org/36523817. This version to me is more intuitive. But NSF still won’t connect from a remote client to a server on this machine.
It’s not clear to me what if anything has changed since my 01/27/20 post, but I believe it is still necessary to manually configure FirewallD for some services.