docker-proxy getting accept4: bad file descriptor

Question

I am trying to add a port forwarding to docker container using docker-proxy but experiencing this error below,

Here are the details,

• A container with IP 172.17.0.2 is already running with --net=none. We are providing our own network and not using docker0 network.

• Now we want to expose some ports of container to host, so thought of trying docker-proxy.

• we executed the below command,

  $ docker-proxy -container-ip 172.17.0.2 -container-port 8000 -host-ip 0.0.0.0   -host-port 8000 -proto tcp
   and we are getting,
   2017/03/16 10:02:30 Stopping proxy on tcp/[::]:8001 for tcp/172.17.0.2:8001 (accept tcp [::]:8001: accept4: bad file descriptor)
  

Docker version: Docker version 17.03.0-ce, build 60ccb22

Answer 1

I don't think there's any other way of doing this but stopping the container, removing it, then running it again starting from a Dockerfile or simply with docker run by adding -p 8000:8000. Docker doesn't seem to let you tinker with docker-proxy directly, you have to use the standard commands.

You could also manually expose the port to outside access by directly changing the iptables, i.e. DOCKER chain in the NAT table and the DOCKER chain in filter. For instance:

iptables -t nat -A DOCKER ! -i your_bridge0 -p tcp -m tcp --dport 8000 -j DNAT --to-destination 172.17.0.2:8000

And:

iptables -A DOCKER ! -i your_bridge0 -o your_bridge0 -d 172.17.0.2 -p tcp --m tcp --dport 80 -j ACCEPT

Of course then you'd have to make sure that the rules are going to stick, which is quite a different problem altogether. Docker doesn't seem to care much about who manages iptables (ufw, firewalld etc.).

This will work, even if docker proxy isn't running at all. docker-proxy binds to the host's ports, which means you control the traffic on the INPUT chain in the filter table (so the host itself). I still haven't figured out why docker was built this way, but by default, if you expose a container (using -p) and then you delete the DNAT rule, it will still work, because the request is going to hit the INPUT chain directly. Which is mind-boggling, but never mind.