How did you solve this issue on your machine?
It only happened to me a couple of times and I didn't get the chance to write down the steps due to being in rush. I recall having to run the fsck.ext4 on the ext4 partition that had the root file system. Something like the below (this only applies if using x86/x86_64 with ext4 fs, not squash fs):
# to check the path of the partition, use fdisk on the disk path then type the letters p then q.
# type m for more help. Here it is assumed that /dev/sda is the disk in use but it could
# a different path (in most cases it's usually /dev/sda)
fdisk /dev/sda
# use fsck to resolve corruption with the partition based on the path shown in fdisk, it
# should be the partition that does not have boot flag on. Answer the questions with y.
fsck.ext4 /dev/sda2
reboot
If the above didn't work due to command not found, then I guess you'll have to use a "Linux LiveCD" or a "Bootable Gparted image" and mount the disk to it to be able to run the above commands and fix the corruption.
Thanks, I already tried that, I'll have to reinstall as it installed in a GPT instead of MBR, and the destined computer only has Legacy bios anyway.
The question is how do I avoid this happening in the future, where the answer is not a UPS.
docker exec -it pihole ping 192.168.1.1
PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data.
From 192.168.1.3 icmp_seq=1 Destination Host Unreachable
From 192.168.1.3 icmp_seq=2 Destination Host Unreachable
From 192.168.1.3 icmp_seq=3 Destination Host Unreachable
Reinstalled, did the guide step by step again, still no ping outside.
Having the same issue: no internet connection form inside a container. There are some comments in /etc/config/dockerd about it being incompatible with fw4; that could be why it is not working at this time.
1 Like
Thanks for the tip. 
On my NanoPi5 with Docker i use OpenWrt 22.03.0-rc6 and I also have the problem that i can't send a ping from my Docker container to the outside.
In /etc/config/dockerd I found this line
config firewall 'firewall
option device 'docker0'
#list blocked_interfaces 'wan'
I commented out the list blocked_interfaces and restarted it. After that everything worked fine.
Please do not use in productive environments!
1 Like
Is it because it is now exposed to the Internet?
1 Like
It's because I don't know exactly what the setting does. I still have to try that out. I use the NanoPi R5S here anyway only in a protected LAN.
In my config for dockerd i miss this line
# option extra_iptables_args '--match conntrack ! --ctstate RELATED,ESTABLISHED' # allow outbound connections
so i think it's better to do this
config firewall 'firewall'
option device 'docker0'
list blocked_interfaces 'wan'
option extra_iptables_args '--match conntrack ! --ctstate RELATED,ESTABLISHED' # allow outbound connections
That work for me. Can someone with iptables knowledge confirm this? Thanks.
That is a good reason 
I myself moved to LXC containers: they just work and do not require messing with firewall rules.
1 Like
I tried LXC container today. so much better than the Docker tinkering. Yesterday lost several hours with Docker / Firewall (OpenWrt 22.03.0-rc6).
Today about two hours and my unbound with ad blocker is running and not a problem with the firewall
I will probably replace the Docker containers with LXC containers. Thanks for the tip!
hi,
- dockerd officially supports iptables only not nftables which is the core fw element in 22.03.
- dockerd service requires some fix (search in the forum for the possible solution) to work in 22.03 properly.
- blocked_interface + extra_iptables_args are the right way: first tells disallow communication between dockerd network stack and those interfaces in the list; 2nd tells, as explained by the comment, to make outgoing traffic from docker network and accept reply traffic. obviously if you don't want to allow wan (or any other interface) to communicate with dockerd network stack just use blocked_interface option.
LXC is indeed a good alternative if you are not short of storage and if you're happy to do manual upgrades of OS + app instead of docker pull & recreate & run sequence. there are benefits on both sides, use what is better for you. or you can even use both parallel.
2 Likes
LXC feels so much light weight vs Docker and takes less space as well. Just like in Docker, it is possible to control resources and priorities and do other tricks.
Would having iptables legacy or the iptables to nftables package (I can't seem to remember the exact name honestly) help to make it work then?
see point 2 - it works (more or less) if you do those fixes.
1 Like
Circling back on this one. I've followed the same tutorial listed in OP and still have internet. It looks like @grrr2 said something can work, with fixes, but need to search for those fixes. I've also read the other thread about nftables and dockerd, but still have no luck
Are there a definitive list of fixes which allows pihole to be run via macvlan with OpenWRT and nftables?
Thanks!
hi,
why you need macvlan?
what if you just use --network=host, fire up pihole, adjust ports as needed (e.g. move default dnsmasq to port 54 instead of 53 allowing pihole to bind port 53 etc).
i use adguard home with this kind of approach and it works. i could even use adguard as dhcp server, which i don't (*), so dnsmasq is still there but that's up to you.
(*) because it is very limited, only supports one interface for example.
I ran into a similar problem. Hereby my solutions and follow up question:
I am using 22.03.5 on armv8 device (Fast Rhino R68S) the original tutorial docker image 2021.09 couldn't be pulled. So I have to use the :latest pihole docker image.
PROBLEM 1:
When docker compose up the pihole docker, logs shows 10-fixroutes.sh not found ??!! Can't start the container normally.
Work around: comment out 10-fixroutes.sh script in the volumn section, then the run them manually by:
docker exec -it pihole /bin/bash
PROBLEM 2:
LAN PC and ping 192.168.1.3. From PiHole webadmin, DNS query can be received from LAN, but couldn't proceed them to dns.google (no reply)
From the shell of pihole docker, it can ping all the lan devices IP EXCEPT 192.168.1.1 (the router). Pihole docker can't ping any external IP.
Work around: luci Firewall - Zone Settings - General Setting - Forward : change from reject to accept
Bingo!
Now the pihole docker can ping 8.8.8.8, LAN device can also do nslookup openwrt.org 192.168.1.3
QUESTION:
What is the safety risk of changing default Forward from REJECT to ACCEPT? Any other more safe way of tuning the firewall to allow pihole-docker to reach the internet?
Thank you!
I'm not sure if this is possible with pi-holes image, but I believe what you can do is turning the docker container into a host container you might have to do this inside lucis dockerman or maybe it is already a hosted container?
Which basicly means that docker image gets its own bridge device, then you can create a unmanaged interface and use this bridge under a custom firewall zone.
Having the global forward option to accept is considered unsafe although only if the device is directly connected as a isp modem, basicly that kinda disables the firewall.
Then the only thing you want to do is...
go to firewall>traffic rules and then create a new rule, src is the zone of your lan clients and destination zone is the new zone you created, optional you could also choose to use the ip from your new container in the dhcp dns forwardings options that way if clients uses your router ip as dns it forwards to pi-hole.
@grrr2 Would you please elaborate a bit how move default dnsmasq to port 54?
I tried to goolge but kind of lost
Many thanks!
Thank you for your reply. Yes I read a bit on the default firewall, setting forward to accept is not an good idea.
Re: src is the zone of your lan clients and destination zone is the new zone you created,
Excuse I am bit confused,
"src is the zone of your lan clients" - OK
"destination zone is the new zone you created" - what new zone? Did I miss anything?
Thank you!