2

I'm trying to open ftp port in the public zone and firewall-cmd exits with a very non-descriptive response. Command output is:

firewall-cmd --zone=public --add-service=ftp
Error: COMMAND_FAILED

OS: CentOS Linux release 7.3.1611 (Core)


Updating original question with more details.

journalctl output:

~ firewall-cmd --zone=public --add-service=ftp
Error: COMMAND_FAILED
~ journalctl -xf
Mar 06 00:46:42 hostname firewalld[3496]: ERROR: COMMAND_FAILED

debug output:

~ firewalld --nofork --debug=10
<...>
2017-03-06 00:49:57 DEBUG1: zone.addService('public', 'ftp', 0)
2017-03-06 00:49:57 DEBUG4: <class 'firewall.core.fw_transaction.FirewallZoneTransaction'>.execute(True)
2017-03-06 00:49:57 DEBUG4: <class 'firewall.core.fw_transaction.FirewallZoneTransaction'>.prepare(True, ...)
2017-03-06 00:49:57 DEBUG4: <class 'firewall.core.fw_transaction.FirewallZoneTransaction'>.prepare(True, ...)
2017-03-06 00:49:57 DEBUG4: <class 'firewall.core.fw_transaction.FirewallZoneTransaction'>.pre()
2017-03-06 00:49:57 DEBUG2: <class 'firewall.core.ipXtables.ip4tables'>: /usr/sbin/iptables-restore /run/firewalld/temp.tptEtP: 89
       1: *filter
       2: -A IN_public_allow -p tcp --dport 21 -m conntrack --ctstate NEW -j ACCEPT
       3: COMMIT
2017-03-06 00:49:57 DEBUG2: <class 'firewall.core.ipXtables.ip6tables'>: /usr/sbin/ip6tables-restore /run/firewalld/temp.CYsjiA: 89
       1: *filter
       2: -A IN_public_allow -p tcp --dport 21 -m conntrack --ctstate NEW -j ACCEPT
       3: COMMIT
2017-03-06 00:49:57 DEBUG2: <class 'firewall.core.modules.modules'>: /sbin/modprobe nf_conntrack_ftp
2017-03-06 00:49:57 DEBUG2: <class 'firewall.core.ipXtables.ip4tables'>: /usr/sbin/iptables-restore /run/firewalld/temp.1dBrUZ: 89
       1: *filter
       2: -D IN_public_allow -p tcp --dport 21 -m conntrack --ctstate NEW -j ACCEPT
       3: COMMIT
2017-03-06 00:49:57 DEBUG2: <class 'firewall.core.ipXtables.ip6tables'>: /usr/sbin/ip6tables-restore /run/firewalld/temp.vbUyZC: 89
       1: *filter
       2: -D IN_public_allow -p tcp --dport 21 -m conntrack --ctstate NEW -j ACCEPT
       3: COMMIT
2017-03-06 00:49:57 ERROR: COMMAND_FAILED

One more update: if I do:

~ iptables -A IN_public_allow -p tcp --dport 21 -m conntrack --ctstate NEW -j ACCEPT

ftp service is working. However I'd like to manage everything via firewalld. So I'm wondering if it is a firewalld glitch or error in configuration.

  • 1
    You may find more information in the journal. – Michael Hampton Mar 5 '17 at 21:06
  • Unfortunately firewalld log and even 'firewalld --nofork --debug=10' provide the same brief error: COMMAND_FAILED – nweb Mar 5 '17 at 21:23
  • are you root? is this a virtual server or bare metal? this might be related to limits of the guest. you might want to read certdepot.net/rhel7-get-started-firewalld which seems to describe the process as well – Dennis Nolte Mar 5 '17 at 21:40
  • I am root. Server is a virtual machine. I can successfully open any other ports except ftp. – nweb Mar 5 '17 at 21:44
  • What is the underlying hypervisor? if it is OpenVZ then you will not be able to control the firewall. if it's not then as Michael suggested, look in the journal. – Iain Mar 5 '17 at 21:50
2

Same issue, but --add-port worked for me:

# firewall-cmd --zone=public --add-port=21/tcp
  • That doesn't quite work for me - I am unable to load nf_conntrack_ftp. Is 8 GB of RAM not enough to open FTP ports for firewalld? Also, when I modprobe -v nf_conntrack_ftp I get the error - not enough memory to load, unloading. – The Dude Jul 11 '17 at 15:19
0

This answers the problem of LXC guest with host that supports it. Does your LXC support this?

Host needs to have support modprobe nf_conntrack_ftp lsmod shows nf_conntrack_ftp? if so add nf_conntrack_ftp to /etc/modules Capture the output of modinfo nf_conntrack_ftp for later

Supported in your LXC? /sys/module/nf_conntrack_ftp exists? /proc/sys/net/netfilter/nf_conntrack_helper exists? mkdir -p /lib/modules/4.4.67-1-pve/kernel/net/netfilter/ replace 4.4.67-1-pve with your host, I'm using Proxmox with that kernel. touch all those .ko files from the host put the output of modinfo nf_conntrack_ftp into the nf_conntrack_ftp.ko file backup modinfo replace it with this script

#!/bin/bash
cat /lib/modules/4.4.67-1-pve/kernel/net/netfilter/$1.ko

Replace the path with what you created earlier. Make the file executable. You want modinfo nf_conntrack_ftp to have the same output from your host as in your guest.

Next we need to replace modprobe with the following script.

#!/bin/bash
exit 0

Make it executable as well. Because this is the guest it's not like you even have modules to probe.

Great. You can now fool /usr/lib/python2.7/site-packages/firewall/functions.py that your guest can do things with modinfo.

You are also fooling /usr/lib/python2.7/site-packages/firewall/core/modules.py with the modprobe replacement.

Again, I feel it's ok that modinfo and modprobe is replaced with these fake scripts because the guest in a container doesn't have access to modules anyway. This fact is why it doesn't work.

I also think that the firewalld project should fix this as it seems like an unintended bug.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.