🚨 nftables Error: 'nft: Error: Could not process rule: No such file or directory' — Cause, Fix, and Troubleshooting Guide

What this error means

nft tried to add a rule but the object it depends on — the table, the chain, or a kernel feature — does not exist, so the kernel returns ENOENT and nft reports the rule could not be processed. The confusing part is that the “file or directory” is really a firewall object, not a path on disk.

nft: Error: Could not process rule: No such file or directory
add rule inet filter input tcp dport 22 accept
              ^^^^^^^^^^^^

The caret under the failing token tells you which reference nft could not resolve — usually a table/chain that was never created, or a family mismatch.

How it manifests on the host

• nft add rule ... fails immediately with Could not process rule: No such file or directory.
• nft -f /etc/nftables.conf aborts partway, leaving a half-applied ruleset.
• A rule referencing a set or map fails even though the set name looks correct.
• The same rule works on one host but fails on a minimal/container kernel.

System configuration causes

• Missing table. You added a rule into inet filter but never ran add table inet filter.
• Missing chain. The table exists but the target chain (e.g. input) was not created with a hook.
• Family mismatch. The rule targets ip filter while the table was created as inet filter (or vice versa).
• Ordering in a script. A ruleset file references a set/chain defined later in the same file.
• Missing kernel module/feature. nf_tables or a specific expression (e.g. nftables connection tracking) is not available on a stripped-down kernel.

Interrogating the host

# What tables and chains actually exist right now?
sudo nft list ruleset
sudo nft list tables

# Is the nftables kernel subsystem present?
lsmod | grep -E 'nf_tables|nft_'
sudo modprobe nf_tables && echo loaded

# Validate a ruleset file without committing it (checks syntax + object refs)
sudo nft -c -f /etc/nftables.conf

nft -c -f performs a dry run and reports the exact line/object that cannot be resolved, which is faster than trial and error on a live ruleset.

Remediation

1. Create the table and chain before adding rules (the most common fix):

sudo nft add table inet filter
sudo nft add chain inet filter input '{ type filter hook input priority 0; policy drop; }'
sudo nft add rule inet filter input tcp dport 22 accept

2. Match the family consistently. Decide on inet (covers IPv4+IPv6) and use it everywhere the object is referenced.

3. Order a ruleset file correctly — define tables, then sets/maps, then chains, then rules — and validate before loading:

sudo nft -c -f /etc/nftables.conf   # dry run; fix the flagged line
sudo nft -f /etc/nftables.conf      # apply atomically

4. Load the kernel module on minimal hosts and make it persist:

sudo modprobe nf_tables
echo nf_tables | sudo tee /etc/modules-load.d/nftables.conf

Hardening the host

• Use nft -f for whole-file loads: it applies atomically, so a bad line leaves the previous ruleset intact rather than a half-applied one.
• Never mix iptables-legacy and nft tooling on the same host — coexisting rulesets cause confusing ENOENT/ordering failures.
• Flushing and reloading over SSH can lock you out; stage a rollback (at job or console access) before applying policy drop.
• inet tables simplify dual-stack hosts; splitting ip and ip6 doubles the objects you must keep in sync.

Related system errors

• firewalld ‘COMMAND_FAILED’ iptables Error Guide
• ufw ‘problem running ufw-init’ Error Guide
• CIS Benchmark Hardening for Linux Servers