#1139303 ferm: systemd .service unit breaks NFS-mounted /home

Package:
ferm
Source:
ferm
Submitter:
David Härdeman
Date:
2026-07-03 06:51:02 UTC
Severity:
normal
Tags:
#1139303#5
Date:
2026-06-08 11:36:18 UTC
From:
To:
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

#1139303#10
Date:
2026-06-08 11:58:41 UTC
From:
To:
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

#1139303#17
Date:
2026-06-08 15:35:47 UTC
From:
To:
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

#1139303#22
Date:
2026-06-08 15:33:27 UTC
From:
To:
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

#1139303#31
Date:
2026-06-08 15:45:43 UTC
From:
To:
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

#1139303#36
Date:
2026-06-08 16:05:23 UTC
From:
To:
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

#1139303#43
Date:
2026-07-03 05:56:29 UTC
From:
To:
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

#1139303#50
Date:
2026-07-03 06:49:33 UTC
From:
To:
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-----