Operation not permitted when creating special file.

[zorani]

Hello,

Am using the latest version of unbound-docker, docker pull mvance/unbound:latest ( I think this version, 1.17.0 )

I get the following errors when starting the container fresh with no changes.

cp: cannot create special file '/opt/unbound/etc/unbound/dev/random': Operation not permitted cp: cannot create special file '/opt/unbound/etc/unbound/dev/urandom': Operation not permitted cp: cannot create special file '/opt/unbound/etc/unbound/dev/null': Operation not permitted chown: cannot access '/opt/unbound/etc/unbound/unbound.log': No such file or directory

This is my unbound.conf file taken from this website https://docs.pi-hole.net/guides/dns/unbound/ I have commented out #so-rcvbuf: 1m to solve another error not shown above found in one of your other closed issues. I also added in the username as you mention that in another thread.

server:

If no logfile is specified, syslog is used

# logfile: "/var/log/unbound/unbound.log"
verbosity: 1
username: _unbound
interface: 127.0.0.1
port: 5335
do-ip4: yes
do-udp: yes
do-tcp: yes

# May be set to yes if you have IPv6 connectivity
do-ip6: no

# You want to leave this to no unless you have *native* IPv6. With 6to4 and
# Terredo tunnels your web browser should favor IPv4 for the same reasons
prefer-ip6: no

# Use this only when you downloaded the list of primary root servers!
# If you use the default dns-root-data package, unbound will find it automatically
#root-hints: "/var/lib/unbound/root.hints"

# Trust glue only if it is within the server's authority
harden-glue: yes

# Require DNSSEC data for trust-anchored zones, if such data is absent, the zone becomes BOGUS
harden-dnssec-stripped: yes

# Don't use Capitalization randomization as it known to cause DNSSEC issues sometimes
# see https://discourse.pi-hole.net/t/unbound-stubby-or-dnscrypt-proxy/9378 for further details
use-caps-for-id: no

# Reduce EDNS reassembly buffer size.
# IP fragmentation is unreliable on the Internet today, and can cause
# transmission failures when large DNS messages are sent via UDP. Even
# when fragmentation does work, it may not be secure; it is theoretically
# possible to spoof parts of a fragmented DNS message, without easy
# detection at the receiving end. Recently, there was an excellent study
# >>> Defragmenting DNS - Determining the optimal maximum UDP response size for DNS <<<
# by Axel Koolhaas, and Tjeerd Slokker (https://indico.dns-oarc.net/event/36/contributions/776/)
# in collaboration with NLnet Labs explored DNS using real world data from the
# the RIPE Atlas probes and the researchers suggested different values for
# IPv4 and IPv6 and in different scenarios. They advise that servers should
# be configured to limit DNS messages sent over UDP to a size that will not
# trigger fragmentation on typical network links. DNS servers can switch
# from UDP to TCP when a DNS response is too big to fit in this limited
# buffer size. This value has also been suggested in DNS Flag Day 2020.
edns-buffer-size: 1232

# Perform prefetching of close to expired message cache entries
# This only applies to domains that have been frequently queried
prefetch: yes

# One thread should be sufficient, can be increased on beefy machines. In reality for most users running on small networks or on a single machine, it should be unnecessary to seek performance enhancement by increasing num-threads above 1.
num-threads: 1

# Ensure kernel buffer is large enough to not lose messages in traffic spikes
# so-rcvbuf: 1m

# Ensure privacy of local IP ranges
private-address: 192.168.0.0/16
private-address: 169.254.0.0/16
private-address: 172.16.0.0/12
private-address: 10.0.0.0/8
private-address: fd00::/8
private-address: fe80::/10

Here is my docker-compose.yml file,

version: "3.8" services: pihole: image: pihole/pihole:latest container_name: pihole environment: TZ: 'Europe/Amsterdam' WEBPASSWORD: 'webpassword' DNS1: '127.0.0.1#5335' ports:

• "127.0.0.1:53:53/tcp"
• "127.0.0.1:53:53/udp"
• "127.0.0.1:80:80" volumes:
• './etc-pihole:/etc/pihole'
• './etc-dnsmasq.d:/etc/dnsmasq.d' networks:
• dns unbound: image: mvance/unbound:latest container_name: unbound ports:
• "127.0.0.1:5335:53/udp" volumes:
• './etc-unbound:/opt/unbound/etc/unbound/' networks:
• dns

networks: dns: driver: bridge

The permissions on my attached volume on my host system,

total 32 drwxr-xr-x 2 myuser myuser 4096 Jan 26 16:56 dev -rw-rw-r-- 1 myuser myuser 3071 Jan 26 16:56 unbound.conf -rw-r--r-- 1 myuser myuser 13491 Jan 26 16:56 unbound.conf.bkp -rw-r--r-- 1 100999 100999 2 Jan 26 16:56 unbound.pid drwx------ 2 100999 100999 4096 Jan 26 16:56 var

The permissions for these same files from inside

root@201ec8aced78:/opt/unbound/etc/unbound# ls -l total 32 drwxr-xr-x 2 root root 4096 Jan 26 15:56 dev -rw-rw-r-- 1 root root 3071 Jan 26 15:56 unbound.conf -rw-r--r-- 1 root root 13491 Jan 26 15:56 unbound.conf.bkp -rw-r--r-- 1 _unbound _unbound 2 Jan 26 15:56 unbound.pid drwx------ 2 _unbound _unbound 4096 Jan 26 15:56 var

My naive attempt from inside docker container,

root@201ec8aced78:/opt/unbound/etc/unbound# chown _unbound:_unbound -R dev/ root@201ec8aced78:/opt/unbound/etc/unbound# ls -l total 32 drwxr-xr-x 2 _unbound _unbound 4096 Jan 26 15:56 dev -rw-rw-r-- 1 root root 3071 Jan 26 15:56 unbound.conf -rw-r--r-- 1 root root 13491 Jan 26 15:56 unbound.conf.bkp -rw-r--r-- 1 _unbound _unbound 2 Jan 26 15:56 unbound.pid drwx------ 2 _unbound _unbound 4096 Jan 26 15:56 var

Which changed the permissions as seen from my volume to,

total 32 drwxr-xr-x 2 100999 100999 4096 Jan 26 16:56 dev -rw-rw-r-- 1 myuser myuser 3071 Jan 26 16:56 unbound.conf -rw-r--r-- 1 myuser myuser 13491 Jan 26 16:56 unbound.conf.bkp -rw-r--r-- 1 100999 100999 2 Jan 26 16:56 unbound.pid drwx------ 2 100999 100999 4096 Jan 26 16:56 var

This still gave the same error as before.

I am running on Linux mint 21.1

I did find the following similar thread, https://github.com/MatthewVance/unbound-docker/issues/60, and the threads it leads to but I can't seem to find an exact fix for the above problem.

Hope you can help.

edit:

Just in case this is useful info. I am running docker as a normal user, installed docker desktop with no modifications.

I did notice that even though my pi-hole container works I just can't add to white list, or black list, or add advert lists or any other changes that need a database write.

To solve this I apply chown -R www-data:pihole /etc/pihole from inside my pi docker container when ever I want to update the pihole database.

So, it seems that now with 2 docker images there is a problem run as a normal user.

I suspect running the containers as root might help but I want to avoid that if possible.

edit 2:

I also though it could be a docker uid gid issue.

Checking my host user account, myuser: x :1000:1000:myuser,,,:/home/myuser:/bin/bash

and comparing with _ubound,

_unbound: x :1000:1000::/etc:/dev/null

same UID and GID so that doesn't look like the issue.

[MatthewVance]

Hello, I'm not sure if you found it when searching through other issues, but I outlined some config settings for using this image with Pi-hole in this issue discussion. My guess is interface: 127.0.0.1 part of your issue.

[bensisco]

Hello,

i got the same issue as zorani is describing, i also found no solution so far:

cp: cannot create special file '/opt/unbound/etc/unbound/dev/random': Operation not permitted cp: cannot create special file '/opt/unbound/etc/unbound/dev/urandom': Operation not permitted cp: cannot create special file '/opt/unbound/etc/unbound/dev/null': Operation not permitted

I am really interested in a solution that will fix this issue.

Executing the above commands inside the container being root leads to the described errors too.

I am also using the latest version of unbound-docker, docker pull mvance/unbound:latest, also with a volume "/etc-unbound:/opt/unbound/etc/unbound/. I am using portainer to setup containers, networks, volumes, ports, ...

To solve the Problem with

chown: cannot access '/opt/unbound/etc/unbound/unbound.log': No such file or directory

i did what is written in unbound.conf: "# If you want to log to a file, use: logfile: /opt/unbound/etc/unbound/unbound.log"

Uncommenting the line "# logfile: /opt/unbound/etc/unbound/unbound.log" helped.

[MatthewVance]

I'm not familiar with Portainer (or Podman). However, I saw a recent comment from @Zanathoz that may have help.

https://github.com/MatthewVance/unbound-docker/issues/22#issuecomment-1637097448

[Zanathoz]

Unfortunately appending :Z doesn't help for this issue as I still have it, but it doesn't appear to hinder DNS resolution.

I did find this issue in my research but haven't been able to devote much more time to troubleshooting.