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

Package:
ferm
Source:
ferm
Submitter:
David Härdeman
Date:
2026-06-08 16:07: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