Operation not permitted

[Tomatensauce]

Describe the bug

After starting the container in my docker using portainer, unbound logs produce the following msg:

cp: preserving times for '/opt/unbound/etc/unbound/dev/random': Operation not permitted cp: preserving times for '/opt/unbound/etc/unbound/dev/urandom': Operation not permitted cp: preserving times for '/opt/unbound/etc/unbound/dev/null': Operation not permitted [0] libunbound[18:0] error: gettimeofday: Operation not permitted

With portainer, I create a volume for my unbound and "map /opt/unbound/etc/unbound" to this volume. Due to a mcvlan, I can give unbound a own IP Adresse and publish the ports 53 TCP/UDP.

I also set NET_ADMIN as a capability.

Only, if I set the "privileged mode - on" at the runtime section, unbound starts and is healthy. Is this behavior wanted?

To Reproduce Steps to reproduce the behavior:

1. Docker run command or compose file: mvance/unbound-rpi:latest
2. Customizations (config files) - no custom config
3. Directory structure '....' - standard
4. See error

Expected behavior healthy unbound serivce

Error messages

cp: preserving times for '/opt/unbound/etc/unbound/dev/random': Operation not permitted cp: preserving times for '/opt/unbound/etc/unbound/dev/urandom': Operation not permitted cp: preserving times for '/opt/unbound/etc/unbound/dev/null': Operation not permitted [0] libunbound[18:0] error: gettimeofday: Operation not permitted

Additional context Add any other context about the problem here.

[MatthewVance]

Thanks for the detailed report. I have zero experience with portainer so I'm not sure I'll be able to help. One thing that seems odd is you mention creating and mapping a volume, but not using a custom config. A suspect this is the source of the issue. What happens if you run without a volume?

docker run \
--name=unbound \
--detach=true \
--publish=53:53/tcp \
--publish=53:53/udp \
--restart=unless-stopped \
mvance/unbound:latest

Also, I see your pulling the Raspberry Pi images, but reporting this on the standard repo. Is this intentional? The Pi image won't work on an x86 processor.

[NotSoFunnyClown]

I got a similar problem with an Intel NUC on a Proxmox Host.

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
[1658763042] unbound[1:0] error: Could not open logfile /dev/null: Permission denied
[1658763042] unbound[1:0] info: start of service (unbound 1.16.1).

It's called here: https://github.com/MatthewVance/unbound-docker/blob/7acaaa39da0f6da0fd55ce06ec4f40b82d77b7b4/1.16.1/data/unbound.sh#L360

Unbound runs anyway but it's strange :/

[telnetdoogie]

I have this problem too. I think the logs based on the default config are sent to /dev/null but there's a /opt/unbound/etc/unbound/dev/null that it's trying to output to. Perhaps /opt/unbound/etc/unbound/dev/null is not correctly linked to /dev/null or something similar. This error happens even with a clean container build and no mapped volumes for me.

# cd /opt/unbound/etc/unbound/dev/
# echo 'hello' > null
/bin/sh: 21: cannot create null: Permission denied
# cd /dev/
# echo 'hello' > null

the /dev/null in the opt unbound folder does not behave the same as /dev/null inside the container.

[MatthewVance]

It’s likely the chroot causing this.

On Aug 20, 2022, at 5:37 PM, Jason Hobbs @.***> wrote:

 I have this problem too. I think the logs based on the default config are sent to /dev/null but there's a /opt/unbound/etc/unbound/dev/null that it's trying to output to. Perhaps /opt/unbound/etc/unbound/dev/null is not correctly linked to /dev/null or something similar. This error happens even with a clean container build and no mapped volumes for me.

cd /opt/unbound/etc/unbound/dev/

echo 'hello' > null

/bin/sh: 21: cannot create null: Permission denied

cd /dev/

echo 'hello' > null

the /dev/null in the opt unbound folder does not behave the same as /dev/null

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you commented.

[vargylet]

I'm running unbound in a VM using Proxmox without any issues. I tried to run it in an LXC instead and have the exact same issue as @NotSoFunnyClown. unbound works, but it throws the permission errors.

docker-compose.yml

version: "3"

networks:
  dns-network:
    name: dns-network

services:
  unbound:
    image: mvance/unbound:latest
    container_name: unbound
    networks:
      - dns-network
    ports:
      - "53:53/tcp"
      - "53:53/udp"
    restart: always

docker logs

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
[1676660973] unbound[1:0] error: Could not open logfile /dev/null: Permission denied
[1676660973] unbound[1:0] info: start of service (unbound 1.17.0).

To verify my docker-compose.yml I just ran it in a new VM without the above issue. Maybe LXC related somehow?

[telnetdoogie]

I suspect this is related to specific hosts and the default options on filesystem mounts inside docker / containers. On a synology, for example, checking the mount options of the root filesystem from within the container:

/dev/vg1000/lv on / type btrfs (rw,nodev,relatime,ssd,synoacl,space_cache=v2,auto_reclaim_space,metadata_ratio=50,syno_allocator,subvolid=5321,subvol=/@syno/@docker/btrfs/subvolumes/17b22bd50035becae7261ac34d4c9cb24dad5e405078e1d1a3211cbfc321a6dd)

...I believe this is a chroot issue with the nodev option on the filesystem (docker volume)

See https://superuser.com/questions/1310770/fixing-dev-null-permission-denied-repeatedly-in-chroot

@vargylet since you have two hosts available to run this image, one that has the issue and one that does not, perhaps you could validate whether the problematic version also shows nodev as a mount option for the root filesystem, and whether that's NOT present on the non-problematic version?

[vargylet]

Sure thing! I had a look, but it didn't really help, I'm afraid.

VM: /dev/sda1 on / type ext4 (rw,relatime,errors=remount-ro) LXC: /var/lib/vz/images/111/vm-111-disk-0.raw on / type ext4 (rw,relatime)

[telnetdoogie]

appreciated! maybe these aren't the droids...

[s17534]

Hi! I had the same problem with errors:

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  

My setup is Proxmox PVE, unbound was running in docker container inside unprivileged LXC.

After many considerations and failed attempts to solve this issue, I finally make it go away with checking this little option, it's in the Proxmox webUI > lxc container > options > Features > Edit > Create device nodes (check!)

And that was it!