Dear maintainers,
The systemd unit introduced in 2.7-3 added:
After=network.target remote-fs.target
This was changed (fixing #1137558) in 2.7-4 to:
After=remote-fs.target
This still breaks if a remote fs is actually configured.
In my case, I have workstations where /home is NFS-mounted (via fstab)
This automatically creates units like home.mount, which remote-fs.target depends on
("systemctl list-dependencies remote-fs.target"), but these auto-created units
have a dependency on network-online.target, meaning that a loop is created.
In my case, systemd dropped network-manager.service and network-online.target,
meaning the workstations came up with no networking at all.
My local fix (works for me, not 100% sure this is the right way) was
a drop-in like this:
/etc/systemd/system/ferm.service.d/override.conf
After=
After=systemd-journald.socket basic.target
Cheers,
David
Control: severity -1 important Thanks Current ferm in unstble has the following unit: [Unit] Description=Firewall configuration with ferm Documentation=man:ferm(1) After=remote-fs.target Before=network-pre.target Wants=network-pre.target ConditionPathIsExecutable=/usr/sbin/ferm ConditionPathExists=/etc/ferm/ferm.conf [Service] Type=oneshot RemainAfterExit=yes EnvironmentFile=-/etc/default/ferm # Set defaults for variables not in environment file # (EnvironmentFile takes precedence, see systemd.exec(5) Environment="CACHE=no" Environment="OPTIONS=" # Execute wrapper ExecStart=/usr/libexec/ferm/ferm-systemd activate ExecReload=/usr/libexec/ferm/ferm-systemd activate ExecStop=/usr/libexec/ferm/ferm-systemd deactivate UMask=0077 # Security hardening PrivateTmp=yes ProtectSystem=strict ProtectHome=yes ReadWritePaths=/var/cache/ferm /run NoNewPrivileges=no # Required capabilities for firewall management AmbientCapabilities=CAP_NET_ADMIN CAP_NET_RAW CapabilityBoundingSet=CAP_NET_ADMIN CAP_NET_RAW CAP_SYS_MODULE [Install] WantedBy=multi-user.target Does this solve the issue for you or at least make the situation better? Generally, I would advise to delay the /home NFS mount until the network is fully up and firwalled. Greetings Marc
Thank you very much for filing the bug for the version in stable, causing me to spend about half an hour of my private volunteer time trying to understand a problem that DIDNT EXIST IN THE CODE I REVIEWED. I will probably get back to your issue on the weekend. Greetings Marc
June 8, 2026 at 1:58 PM, "Marc Haber" <mh+debian-packages@zugschlus.de> wrote: Thanks for the prompt reply :) Yes, I'm using ferm from unstable (i.e. 2.7-5), so that matches my current .service file. The problem is the "After=" line, I don't think the firewall should try to come up *after* remote file systems. After=network.target remote-fs.target And now it's only: After=remote-fs.target And I think that "After=network.target" could also have caused issues. Yeah, I agree that mounting NFS file systems after the network is firewalled makes sense. But that's the problem: the .service file now says that "ferm.service" should be ordered "After=remote-fs.target", which basically states the opposite. And having the NFS /home mount as part of remote-fs.target is not really my choice, that's what systemd does automatically for filesystems marked as _netdev in fstab (or, I think, for filesystems with fstype "nfs" where it can autodetect it). (It also makes sense that the remote file systems (like NFS) would be part of "remote-fs.target", that's pretty much what the target is for) Regards, David
June 8, 2026 at 5:35 PM, "Marc Haber" <mh+debian-packages@zugschlus.de mailto:mh+debian-packages@zugschlus.de> wrote: I'm sorry, I filed the bug against 2.7-3, which was uploaded on 23 May 2026 to unstable and which introduced the systemd .service file (according to the changelog) [1]. The version in stable is 2.5.1-4 as far as I can tell [2]? Or have I misunderstood something? Kind regards, David [1] https://metadata.ftp-master.debian.org/changelogs//main/f/ferm/ferm_2.7-5_changelog [2] https://packages.debian.org/search?keywords=ferm
control: tags -1 help control: retitle -1 current ferm cannot be used on NFS clients thanks Hello, Can you make some sense from https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=863802#56 ? I won't have the time to build a test environment for NFS any time soon. Greetings Marc
Hello, Bug #1139303 in ferm reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/debian/ferm/-/commit/733c66287996edb246bdd8fe1dfb14926f06e391 ------------------------------------------------------------------------ implement two-phase startup have ferm-early.service that establishes a very basic, independent ruleset (doumenting that this ruleset MUST NOT assume any network functionality such as interface names, IP addresses, DNS) that runs before any network initialization begins (Before: network-pre.target). A second ferm.service is then started After: network-online.target which contains the full ruleset. Once ferm.service is started, ferm-early.service is inhibited for for the run time of this boot. Thanks: Moritz Muehlenhoff, David Härdeman, Gabor Kiss, Closes: #863802, #1139303 ------------------------------------------------------------------------ (this message was generated automatically) -- Greetings https://bugs.debian.org/1139303
We believe that the bug you reported is fixed in the latest version of
ferm, which is due to be installed in the Debian FTP archive.
A summary of the changes between this version and the previous one is
attached.
Thank you for reporting the bug, which will now be closed. If you
have further comments please address them to 1139303@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.
Debian distribution maintenance software
pp.
Marc Haber <mh+debian-packages@zugschlus.de> (supplier of updated ferm package)
(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@ftp-master.debian.org)
Format: 1.8
Date: Fri, 03 Jul 2026 07:59:34 +0200
Source: ferm
Architecture: source
Version: 2.7-6
Distribution: unstable
Urgency: medium
Maintainer: Debian Ferm Maintainers <ferm@packages.debian.org>
Changed-By: Marc Haber <mh+debian-packages@zugschlus.de>
Closes: 863802 1139303
Changes:
ferm (2.7-6) unstable; urgency=medium
.
* update README
* some fixes to README.source
* implement two-phase startup
Thanks to Moritz Muehlenhoff, David Härdeman, Gabor Kiss,
(Closes: #863802, #1139303)
Checksums-Sha1:
29990498d926e9300b3f8e830384dc945f38cc2e 2113 ferm_2.7-6.dsc
c5db4e4447db0775a8e1acc1b911b6612823863a 24260 ferm_2.7-6.debian.tar.xz
Checksums-Sha256:
7d1d2a583882c43b6c2987c3982fad25e419856553b801b62b528d90993cf0d0 2113 ferm_2.7-6.dsc
5888c06f696ef117fb0bb3042e24624999c82ddb19e216334c200aed369ee8b9 24260 ferm_2.7-6.debian.tar.xz
Files:
a0a36288831a5a99ac034b3c465befdd 2113 net optional ferm_2.7-6.dsc
ea6a92629b61ac89f00f10ad2a3069d8 24260 net optional ferm_2.7-6.debian.tar.xz
-----BEGIN PGP SIGNATURE-----
iQIzBAEBCgAdFiEE6QL5UJ/L0pcuNEbjj3cgEwEyBEIFAmpHVtkACgkQj3cgEwEy
BEJ3+hAA291PxpWsuR/zhTDKBtJsff6z/l1tk23M0v6dLTmhpet53ZbCjMb543dy
3rP2xzWo/4MqURtsNNv/jZKXwAmCnUf8ctoQ2csB58/MSNujuMGsjH8EpbB2w//s
oVDzF9s9A2m2dqxk4SA9m462wTpBRhkqIkFHPHr8IDPIyl80qxleRYa8S8yc8Cfd
ug0x/QDvpxIlNHr1AAbAc0v+n3kZ81CFvVBgmhNMnLnaIxapfSLP1kim4WVGnYd2
n+OElI854CgLA2Hlj1spDS1eTRnVSweTEbGW7/GR6Kuh19ujvQIoYTP7sEmdf7JZ
mfK9n1rbjVpouRikzOQd9PGVXBwZqh3uIRHuS1Oay1bGmVoitFCWOG95Cr6XagFd
b5xXv1lK7QuNTb66ZZWZDsaG9K91+4RSj4DYIhaljq9HayHyO+SGo4CS0kGikkVG
xN5g37D30OpxdLHDWzyfSconG05Fal4E5EeIx8oDZz18Iun9eCmsKaflh1izPSsD
OVck0Ul5o+eElBgtm869WKND8EU756qQK+OKqm8Cvr+4utzbkM65C32yM8LENSIC
+C8C0rGVMtjyz/tQfEEiRtAMUQRyHopFMIaGepwP1sBrlUM+5fyXvgxJM0CQHe3Z
jNzG6v5iNLYC46ztMiGXGhvQ6wI4hoeUp+BsAxO6TTTsNxj4LRg=
=jIwT
-----END PGP SIGNATURE-----