Another app is currently holding the xtables lock. Perhaps you want to use the -w option?

Another app is currently holding the xtables lock. Perhaps you want to use the -w option? means another iptables process is changing the rules at the same moment. iptables takes an exclusive lock on /run/xtables.lock (the default path) before changing rules, and without -w it gives up immediately instead of waiting. Add -w so the command waits for the lock; in scripts that run alongside Docker, Kubernetes or fail2ban, use -w on every call.

What iptables does

The lock belongs to the legacy backend (iptables v1.8.x (legacy), iptables-legacy, and all iptables releases before 1.8). In the iptables source, only iptables.c, ip6tables.c and iptables-restore.c take it; the nf_tables backend (iptables-nft) applies each change as an nftables transaction and does not use this lock. Check which one you run with iptables -V.

In iptables/xshared.c, xtables_lock() opens the lock file and calls flock(). If the lock is busy, xtables_lock_or_exit() prints the message and exits with status 4 (RESOURCE_PROBLEM). With -w SECONDS it waits up to that time and then prints Another app is currently holding the xtables lock. Stopped waiting after Ns. instead. Just before that message iptables also prints the low-level reason, for example Can't lock /run/xtables.lock: Resource temporarily unavailable.

iptables -w -A INPUT -p tcp --dport 8080 -j ACCEPT      # wait as long as needed
iptables -w 10 -A INPUT -p tcp --dport 8080 -j ACCEPT   # wait at most 10 seconds

Run them as root. iptables-restore accepts -w too. The environment variable XTABLES_LOCKFILE changes the lock path, and the default path is set when iptables is built (/run/xtables.lock unless the distribution changed it).

Who holds the lock

fuser -v /run/xtables.lock
lsof /run/xtables.lock
ps -o pid,etime,args -C iptables,iptables-restore,ip6tables

A process that has held the lock for a long time is worth investigating rather than killing: it may be in the middle of an iptables-restore that would leave the rules half-applied.

Containers and Kubernetes

Pods and containers that program the host's firewall (kube-proxy, CNI plugins, network agents) usually mount the host's /run/xtables.lock so that they share one lock with the host. If a container uses its own lock file while changing the host's rules, the lock does not protect anything and concurrent updates can fail in other ways; if it shares the lock, contention shows up as this message, and -w is the fix.