Docker on Synology keeps stopping with Failed to set capabilities for pihole-FTL. Cannot run as non-root.

imro2 commented 2 years ago

This is a: Run Issue (running Pi-hole container failing),

Details

After watchtower pulled latest image, pi-hole docker will not start.

Related Issues

[ ] I have searched this repository/Pi-hole forums for existing issues and pull requests that look similar

How to reproduce the issue

Environment data
- Operating System: Linux Synology 4.4.180+ GNU/Linux synology_geminilake_920+
- Hardware: Synology DS920+
- Kernel Architecture: x86_64
- Docker Install Info and version:
- Software source: official docker
- Supplimentary Software: synology
- Hardware architecture: amd64
docker-compose.yml contents, docker run shell command, or paste a screenshot of any UI based configuration of containers here

version: "2"
services:
  pihole:
    container_name: pihole
    domainname: docker
    hostname: pihole
    image: pihole/pihole:latest
    ports:
      - '53:53/tcp'
      - '53:53/udp'
    expose:
      - 80
      - 443
    networks:
      - proxied
    restart: unless-stopped
    volumes:
      - ${BASEDIR}/pihole:/etc/pihole
      - ${BASEDIR}/pihole.log:/var/log/pihole.log
      - ${BASEDIR}/dnsmasq.d:/etc/dnsmasq.d
    environment:
      - ServerIP=${SERVER_IP}
      - PROXY_LOCATION=pihole
      - VIRTUAL_HOST=pihole.${DOMAINNAME}
      - VIRTUAL_PORT=80
      - TZ=${TZ}
      - DNSMASQ_LISTENING=all
      - WEBPASSWORD=${WEBUIPASS}
      - DNS1=8.8.8.8
      - DNS2=1.1.1.1
      - DNSMASQ_USER:pihole
    dns:
      - 1.1.1.1
      - 1.0.0.1
    labels:
      - "traefik.enable=true"
      - "traefik.backend=pihole"
      ...

any additional info to help reproduce

[fix-attrs.d] applying ownership & permissions fixes...
[fix-attrs.d] 01-resolver-resolv: applying...
[fix-attrs.d] 01-resolver-resolv: exited 1.
[fix-attrs.d] done.
[cont-init.d] executing container initialization scripts...
[cont-init.d] 20-start.sh: executing...
 ::: Starting docker specific checks & setup for docker pihole/pihole
Failed to set capabilities on file `/usr/bin/pihole-FTL' (Operation not supported)
The value of the capability argument is not permitted for a file. Or the file is not a regular (non-symlink) file
ERROR: Failed to set capabilities for pihole-FTL. Cannot run as non-root.
[cont-init.d] 20-start.sh: exited 1.
[cont-finish.d] executing container finish scripts...
[cont-finish.d] done.
[s6-finish] waiting for services.
[s6-finish] sending all processes the TERM signal.
[s6-finish] sending all processes the KILL signal and exiting.
[s6-init] making user provided files available at /var/run/s6/etc...exited 0.
[s6-init] ensuring user provided files have correct perms...exited 0.

These common fixes didn't work for my issue

[ ] I have tried removing/destroying my container, and re-creating a new container
[ ] I have tried fresh volume data by backing up and moving/removing the old volume data
[ ] I have tried running the stock docker run example(s) in the readme (removing any customizations I added)
[x] I have tried a newer or older version of Docker Pi-hole (depending what version the issue started in for me)
[ ] I have tried running without my volume data mounts to eliminate volumes as the cause

Dropping back to version 2021.12.1 resolved the issue

kayaozalp commented 2 years ago

I have the same issue since upgrading to 2022.01 Rolled back to 2021.12.1 and it starts correctly.

grmbl99 commented 2 years ago

Same issue here, I fixed this by adding DNSMASQ_USER=root to my docker-compose.yml file. The default for this was changed from root to pihole

Enn0 commented 2 years ago

the "DNSMASQ_USER=root" fixed it for me.

PromoFaux commented 2 years ago

Does it make a difference if you add the capabilities to the container (without setting the DNSMASQ_USER to root?

https://github.com/pi-hole/docker-pi-hole#note-on-capabilities

for compose yml add:

 cap_add:
      - NET_ADMIN
      - SYS_NICE
      - CHOWN

grmbl99 commented 2 years ago

Does it make a difference if you add the capabilities to the container (without setting the DNSMASQ_USER to root?

https://github.com/pi-hole/docker-pi-hole#note-on-capabilities

for compose yml add:
 cap_add:
      - NET_ADMIN
      - SYS_NICE
      - CHOWN

I tried removing the DNSMASQ_USER=root and adding the above cap_add, but then the 2022.1 image again does not start.

PromoFaux commented 2 years ago

Interesting to know, thanks . I wonder what is different there... I have a synology NAS here that I can try to spin something up on later to play... DSM7 and docker installed via the package manager?

grmbl99 commented 2 years ago

I'm on DSM 6.2.4-25556 Update 2 (which is the latest DSM 6 version) Docker installed via package manager

Enn0 commented 2 years ago

I'm on DSM 6.2.4-25556 Update 2 (which is the latest DSM 6 version) Docker installed via package manager

Same for me.

PromoFaux commented 2 years ago

This might be different for me, as I am on DSM7... don't currently have a way of testing DSM6

but with a very basic compose file of:

version: "3"

# More info at https://github.com/pi-hole/docker-pi-hole/ and https://docs.pi-hole.net/
services:
  pihole:
    container_name: pihole
    image: pihole/pihole
    volumes:
      - './etc-pihole/:/etc/pihole/'
      - './etc-dnsmasq.d/:/etc/dnsmasq.d/'
    # Recommended but not required (DHCP needs NET_ADMIN)
    #   https://github.com/pi-hole/docker-pi-hole#note-on-capabilities
    # cap_add:
    #   - NET_ADMIN
    #   - SYS_NICE
    #   - CHOWN
    restart: unless-stopped

It starts, with or without the cap_add section

r2ixuz commented 2 years ago

For me, 2022.01 is failing at

dnsmasq: cannot access directory /etc/dnsmasq.d: Permission denied
::: Testing pihole-FTL DNS: [cont-init.d] 20-start.sh: exited 1.
[cont-finish.d] executing container finish scripts...
[cont-finish.d] done.
[s6-finish] waiting for services.
[s6-finish] sending all processes the TERM signal.
[s6-finish] sending all processes the KILL signal and exiting.

I did not find any chown at bash_functions.sh for this directory and the user pihole ?

I'm using bindmounts not volumes. OS Gentoo with Docker Version: 20.10.9 amd64

r2ixuz commented 2 years ago

dnsmasq.d directory has 0700 while normally it should have 0755, strange. (Owned by root:root)

grmbl99 commented 2 years ago

For me the the startup failure is caused by the fix_capabilities function in bash_functions.sh I tried running the code manual from a bash shell in the docker container:

root@pihole:~# setcap CAP_NET_BIND_SERVICE,CAP_NET_RAW,CAP_NET_ADMIN,CAP_SYS_NICE,CAP_CHOWN+ei /usr/bin/pihole-FTL 
Failed to set capabilities on file `/usr/bin/pihole-FTL' (Operation not supported)
The value of the capability argument is not permitted for a file. Or the file is not a regular (non-symlink) file

PromoFaux commented 2 years ago

What does your compose file look like?

grmbl99 commented 2 years ago

version: '3'
services:
  pihole:
    image: pihole/pihole:latest
    hostname: pihole
    domainname: redacted
    networks:
      macvlan_network:
        ipv4_address: xxx.xxx.xxx.xxx
    ports:
      - 53/tcp
      - 53/udp
      - 67/udp
      - 80/tcp
      - 443/tcp
    environment:
      - DNS1=1.1.1.1
      - DNS2=1.0.0.1
      - WEBPASSWORD=redacted
      - ServerIP=xxx.xxx.xxx.xxx
      - VIRTUAL_HOST=pihole.redacted
      - TZ=Europe/Amsterdam
      - DNSMASQ_USER=root
    volumes:
      - /volume2/docker/pihole/dnsmasq.d:/etc/dnsmasq.d
      - /volume2/docker/pihole/pihole:/etc/pihole

networks:
  macvlan_network:
    external: true

grmbl99 commented 2 years ago

the above compose file works with 2022.01 when the DNSMASQ_USER=root line is removed it does not work with 2022.01

In both cases, the setcap error is logged, but when DNSMASQ_USER=root, the error is ignored by the script.

PromoFaux commented 2 years ago

Can you try setting each cap individually to see if it is a particular one that is throwing the error?

e.g:

setcap CAP_NET_BIND_SERVICE+ei /usr/bin/pihole-FTL 
setcap CAP_NET_RAW+ei /usr/bin/pihole-FTL 
setcap CAP_NET_ADMIN+ei /usr/bin/pihole-FTL 
setcap CAP_SYS_NICE+ei /usr/bin/pihole-FTL 
setcap CAP_CHOWN+ei /usr/bin/pihole-FTL 
setcap CAP_IPC_LOCK+ei /usr/bin/pihole-FTL

I suspect it's one of the latter three, as they were added in the latest version https://github.com/pi-hole/docker-pi-hole/blob/master/bash_functions.sh#L6

(although I thought I had subsequently removed the CAP_IPC_LOCK check, as it is not required by FTL anyway)

opicron commented 2 years ago

@grmbl99 I see you mapped folders on synology. What permissions do the folders have? I had to add [everybody] because Pihole could not save the settings. Would you mind checking for me?

grmbl99 commented 2 years ago

they all fail with the same error:

Failed to set capabilities on file `/usr/bin/pihole-FTL' (Operation not supported)
The value of the capability argument is not permitted for a file. Or the file is not a regular (non-symlink) file

grmbl99 commented 2 years ago

@grmbl99 I see you mapped folders on synology. What permissions do the folders have? I had to add [everybody] because Pihole could not save the settings. Would you mind checking for me?

I wonder if that is relevant, as the setcap error is on an executable which is not in any of the mapped folders.

PromoFaux commented 2 years ago

At this stage I have to assume this is a docker on DSM6 thing, because I am not seeing this same error on docker on DSM7.

I suppose the workaround is that DNSMASQ_USER is set to root as it used to be (though ideally pihole-FTL should not be running as root - hence the change) Do you see the setcap error on previous versions of the container?

as the setcap error is on an executable which is not in any of the mapped folders.

Yeah, I had wondered if you were doing some odd mapping of /usr/bin, which was what prompted me to ask for your compose file.

Don't suppose you feel like being brave and upping to DSM7 to see if you still see the issue? 😉

Side Note: I actually ended up moving all of my docker containers off of my Synology and onto a Rpi4 as I always felt that docker on Synology was a bit... odd.

grmbl99 commented 2 years ago

Do you see the setcap error on previous versions of the container?

Yep, they were there (at least with the 2021.12.1 version); but it did not block the starting of the container

Don't suppose you feel like being brave and upping to DSM7 to see if you still see the issue?

Nope, no proper USB support (yet) :-)

imro2 commented 2 years ago

@PromoFaux

At this stage I have to assume this is a docker on DSM6 thing, because I am not seeing this same error on docker on DSM7.

For what it is worth, I have the issue on DSM7, though I have not have time to test anything else but going back a version. I will try brand new Docker with caps set later on today.

PromoFaux commented 2 years ago

@grmbl99 can you add FTLCONF_DEBUG_CAPS=true to your environment, and then look for some lines in /var/log/pihole-FTL.log that look like this:

@imro2, thanks for confirming you're seeing it also on DSM7 - odd to note that I am not!

grmbl99 commented 2 years ago

Screenshot 2022-01-04 at 14 59 55

PromoFaux commented 2 years ago

Sorry, and same thing again with the three mentioned caps explicitly set in the compose file (NET_ADMIN, SYS_NICE, IPC_LOCK)

grmbl99 commented 2 years ago

Screenshot 2022-01-04 at 15 08 01

(still running as DNSMASQ_USER=root)

PromoFaux commented 2 years ago

Interesting. Thanks. So that shows that with the caps explicitly set, FTL is able to grab the caps it needs... so the question remains - why does setcap throw that error on container start?

As an experiment, maybe make a copy of start.sh on your host filesystem, comment out the call to fix_capabilities, and then bind mount it to the container? This should then skip the check that causes everyhing to fall over if DNSMASQ_USER is pihole instead of root (needless to say, this experiment should be done with DNSMASQ_USER=root)

rpthms commented 2 years ago

@PromoFaux I'm assuming this is because Docker is not adding the CAP_SETFCAP capabiliity (required to use setcap) in some instances. I haven't tested it out yet but adding the SETFCAP capability to the docker-compose file might fix things.

imro2 commented 2 years ago

@rpthms

I haven't tested it out yet but adding the SETFCAP capability to the docker-compose file might fix things.

does not seem to work for me

grmbl99 commented 2 years ago

@rpthms

I haven't tested it out yet but adding the SETFCAP capability to the docker-compose file might fix things.

does not seem to work for me

same here.

rpthms commented 2 years ago

Yeah, was just a guess. Must be something else then.

grmbl99 commented 2 years ago

Interesting. Thanks. So that shows that with the caps explicitly set, FTL is able to grab the caps it needs... so the question remains - why does setcap throw that error on container start?

As an experiment, maybe make a copy of start.sh on your host filesystem, comment out the call to fix_capabilities, and then bind mount it to the container? This should then skip the check that causes everyhing to fall over if DNSMASQ_USER is pihole instead of root (needless to say, this experiment should be done with DNSMASQ_USER=root)

I'm confused, setting DNSMASQ_USER=root effectively already ignores the setcap errors, which is ok as it is running as root anyway.

PromoFaux commented 2 years ago

whoops, my bad, I meant it should be DNSMASQ_USER=pihole!

imro2 commented 2 years ago

@PromoFaux Here is my attempt with modified start.sh:

pihole-test | [s6-init] making user provided files available at /var/run/s6/etc...exited 0.
pihole-test | [s6-init] ensuring user provided files have correct perms...exited 0.
pihole-test | [fix-attrs.d] applying ownership & permissions fixes...
pihole-test | [fix-attrs.d] 01-resolver-resolv: applying...
pihole-test | [fix-attrs.d] 01-resolver-resolv: exited 1.
pihole-test | [fix-attrs.d] done.
pihole-test | [cont-init.d] executing container initialization scripts...
pihole-test | [cont-init.d] 20-start.sh: executing...
pihole-test |  ::: Starting docker specific checks & setup for docker pihole/pihole
pihole-test | Assigning random password: PCB4bcLz
pihole-test |
pihole-test |   [i] Installing configs from /etc/.pihole...
pihole-test |   [i] Existing dnsmasq.conf found... it is not a Pi-hole file, leaving alone!
  [✓] Installed /etc/dnsmasq.d/01-pihole.conf
  [✓] Installed /etc/dnsmasq.d/06-rfc6761.conf
pihole-test | Applying pihole-FTL.conf setting DEBUG_CAPS=true
pihole-test | Existing DNS servers detected in setupVars.conf. Leaving them alone
pihole-test | ::: Pre existing WEBPASSWORD found
pihole-test | DNSMasq binding to default interface: eth0
pihole-test | Added ENV to php:
pihole-test |                   "PIHOLE_DOCKER_TAG" => "2022.01",
pihole-test |                   "PHP_ERROR_LOG" => "/var/log/lighttpd/error.log",
pihole-test |                   "ServerIP" => "0.0.0.0",
pihole-test |                   "CORS_HOSTS" => "",
pihole-test |                   "VIRTUAL_HOST" => "0.0.0.0",
pihole-test | Using IPv4 and IPv6
pihole-test | ::: Preexisting ad list /etc/pihole/adlists.list detected ((exiting setup_blocklists early))
pihole-test | https://raw.githubusercontent.com/StevenBlack/hosts/master/hosts
pihole-test | ::: Testing pihole-FTL DNS:
pihole-test | dnsmasq: failed to create listening socket for port 53: Permission denied
pihole-test | [cont-init.d] 20-start.sh: exited 1.
pihole-test | [cont-finish.d] executing container finish scripts...
pihole-test | [cont-finish.d] done.
pihole-test | [s6-finish] waiting for services.
pihole-test | [s6-finish] sending all processes the TERM signal.
pihole-test | [s6-finish] sending all processes the KILL signal and exiting.
pihole-test exited with code 1

PromoFaux commented 2 years ago

Have you explicitly set the required caps in the compose file?

imro2 commented 2 years ago

This is my compose file:


version: "3"

# More info at https://github.com/pi-hole/docker-pi-hole/ and https://docs.pi-hole.net/
services:
  pihole:
    container_name: pihole-test
    image: pihole/pihole:latest
    #ports:
    #  - "53:53/tcp"
    #  - "53:53/udp"
    #  - "67:67/udp"
    #  - "80:80/tcp"
    environment:
      TZ: 'America/Chicago'
      FTLCONF_DEBUG_CAPS: ${boolean_true}
      # DNSMASQ_USER: root
      # WEBPASSWORD: 'set a secure password here or it will be random'
    # Volumes store your data between container upgrades
    volumes:
      - './etc-pihole:/etc/pihole'
      - './etc-dnsmasq.d:/etc/dnsmasq.d'
      - './start.sh:/start.sh'
    # Recommended but not required (DHCP needs NET_ADMIN)
    #   https://github.com/pi-hole/docker-pi-hole#note-on-capabilities
    cap_add:
      - NET_ADMIN
      - SYS_NICE
      - IPC_LOCK
      - SETFCAP

imro2 commented 2 years ago

This is my pihole-FTL.log when running with DNSMASQ_USER=pihole and above docker-compose

[2022-01-04 09:08:24.674 318M] ***************************************
[2022-01-04 09:08:24.674 318M] * Linux capability debugging enabled  *
[2022-01-04 09:08:24.674 318M] * CAP_CHOWN                (00) = -I- *
[2022-01-04 09:08:24.674 318M] * CAP_DAC_OVERRIDE         (01) = -I- *
[2022-01-04 09:08:24.674 318M] * CAP_DAC_READ_SEARCH      (02) = --- *
[2022-01-04 09:08:24.674 318M] * CAP_FOWNER               (03) = -I- *
[2022-01-04 09:08:24.674 318M] * CAP_FSETID               (04) = -I- *
[2022-01-04 09:08:24.674 318M] * CAP_KILL                 (05) = -I- *
[2022-01-04 09:08:24.674 318M] * CAP_SETGID               (06) = -I- *
[2022-01-04 09:08:24.674 318M] * CAP_SETUID               (07) = -I- *
[2022-01-04 09:08:24.674 318M] * CAP_SETPCAP              (08) = -I- *
[2022-01-04 09:08:24.674 318M] * CAP_LINUX_IMMUTABLE      (09) = --- *
[2022-01-04 09:08:24.674 318M] * CAP_NET_BIND_SERVICE     (10) = -I- *
[2022-01-04 09:08:24.674 318M] * CAP_NET_BROADCAST        (11) = --- *
[2022-01-04 09:08:24.674 318M] * CAP_NET_ADMIN            (12) = -I- *
[2022-01-04 09:08:24.674 318M] * CAP_NET_RAW              (13) = -I- *
[2022-01-04 09:08:24.674 318M] * CAP_IPC_LOCK             (14) = -I- *
[2022-01-04 09:08:24.674 318M] * CAP_IPC_OWNER            (15) = --- *
[2022-01-04 09:08:24.674 318M] * CAP_SYS_MODULE           (16) = --- *
[2022-01-04 09:08:24.674 318M] * CAP_SYS_RAWIO            (17) = --- *
[2022-01-04 09:08:24.674 318M] * CAP_SYS_CHROOT           (18) = -I- *
[2022-01-04 09:08:24.674 318M] * CAP_SYS_PTRACE           (19) = --- *
[2022-01-04 09:08:24.674 318M] * CAP_SYS_PACCT            (20) = --- *
[2022-01-04 09:08:24.674 318M] * CAP_SYS_ADMIN            (21) = --- *
[2022-01-04 09:08:24.674 318M] * CAP_SYS_BOOT             (22) = --- *
[2022-01-04 09:08:24.674 318M] * CAP_SYS_NICE             (23) = -I- *
[2022-01-04 09:08:24.674 318M] * CAP_SYS_RESOURCE         (24) = --- *
[2022-01-04 09:08:24.674 318M] * CAP_SYS_TIME             (25) = --- *
[2022-01-04 09:08:24.674 318M] * CAP_SYS_TTY_CONFIG       (26) = --- *
[2022-01-04 09:08:24.674 318M] * CAP_MKNOD                (27) = -I- *
[2022-01-04 09:08:24.674 318M] * CAP_LEASE                (28) = --- *
[2022-01-04 09:08:24.674 318M] * CAP_AUDIT_WRITE          (29) = -I- *
[2022-01-04 09:08:24.674 318M] * CAP_AUDIT_CONTROL        (30) = --- *
[2022-01-04 09:08:24.674 318M] * CAP_SETFCAP              (31) = -I- *
[2022-01-04 09:08:24.674 318M] ***************************************
[2022-01-04 09:08:24.674 318M] WARNING: Required Linux capability CAP_NET_ADMIN not available
[2022-01-04 09:08:24.674 318M] WARNING: Required Linux capability CAP_NET_RAW not available
[2022-01-04 09:08:24.674 318M] WARNING: Required Linux capability CAP_NET_BIND_SERVICE not available
[2022-01-04 09:08:24.674 318M] WARNING: Required Linux capability CAP_SYS_NICE not available
[2022-01-04 09:08:24.675 318M] WARNING: Required Linux capability CAP_IPC_LOCK not available
[2022-01-04 09:08:24.675 318M] WARNING: Required Linux capability CAP_CHOWN not available

PromoFaux commented 2 years ago

Someone has just pointed me at this... https://serverfault.com/a/874053.

What storage driver are people's docker systems using? docker system info @imro2 @grmbl99

grmbl99 commented 2 years ago

Someone has just pointed me at this... https://serverfault.com/a/874053.

What storage driver are people's docker systems using? docker system info @imro2 @grmbl99

Storage Driver: aufs
  Root Dir: /volume2/@docker/aufs
  Backing Filesystem: extfs
  Dirs: 984
  Dirperm1 Supported: true

PromoFaux commented 2 years ago

And therein lies the answer. aufs (my synology is overlay2 - so it works)

This might be of use: https://meta.discourse.org/t/how-to-change-storage-backend-in-docker/75352

PromoFaux commented 2 years ago

Probably better to read this though: https://github.com/moby/moby/issues/30557

imro2 commented 2 years ago

And therein lies the answer. aufs (my synology is overlay2 - so it works)

This might be of use: https://meta.discourse.org/t/how-to-change-storage-backend-in-docker/75352

Can I change the storage to overlay2 even though I am using BTRFS? Why is yours set to overlay2? Was this factory? Are you using BTRFS for your Synology volumes?

PromoFaux commented 2 years ago

... Turns out my storage driver is btrfs on the syno, I was SSH'd into a different machine when I looked before 🙈

Complete docker system info from my syno:

admin@fappotron:~$ docker system info
Client:
 Context:    default
 Debug Mode: false

Server:
 Containers: 1
  Running: 1
  Paused: 0
  Stopped: 0
 Images: 46
 Server Version: 20.10.3
 Storage Driver: btrfs
  Build Version: Btrfs v4.0
  Library Version: 101
 Logging Driver: db
 Cgroup Driver: cgroupfs
 Cgroup Version: 1
 Plugins:
  Volume: local
  Network: bridge host ipvlan macvlan null overlay
  Log: awslogs db fluentd gcplogs gelf journald json-file local logentries splunk syslog
 Swarm: inactive
 Runtimes: io.containerd.runc.v2 io.containerd.runtime.v1.linux runc
 Default Runtime: runc
 Init Binary: docker-init
 containerd version: ea3508454ff2268c32720eb4d2fc9816d6f75f88
 runc version: 31cc25f16f5eba4d0f53e35374532873744f4b31
 init version: ed96d00 (expected: de40ad0)
 Security Options:
  apparmor
 Kernel Version: 4.4.180+
 OSType: linux
 Architecture: x86_64
 CPUs: 2
 Total Memory: 9.576GiB
 Name: fappotron
 ID: QGEQ:65ER:5KYD:A5PW:IQO2:HED3:P7S4:SQWT:YS6O:GLSS:IECP:TLLD
 Docker Root Dir: /volume1/@docker
 Debug Mode: false
 Registry: https://index.docker.io/v1/
 Labels:
 Experimental: false
 Insecure Registries:
  127.0.0.0/8
 Live Restore Enabled: false

WARNING: No kernel memory TCP limit support
WARNING: No cpu cfs quota support
WARNING: No cpu cfs period support
WARNING: No blkio weight support
WARNING: No blkio weight_device support
WARNING: No blkio throttle.read_bps_device support
WARNING: No blkio throttle.write_bps_device support
WARNING: No blkio throttle.read_iops_device support
WARNING: No blkio throttle.write_iops_device support

PromoFaux commented 2 years ago

But mine IS allowing setcap to run, so ... back to the drawing board perhaps...

PromoFaux commented 2 years ago

Not sure if this is of any use:

imro2 commented 2 years ago

But mine IS allowing setcap to run, so ... back to the drawing board perhaps...

my storage driver is ausf so I think you are still onto something. I was just asking whether I can change the storage Docker storage driver to something else, even though my Synology is using BTRFS for the actual storage. It is just my not understanding what the Docker storage driver does.


 Storage Driver: aufs
  Root Dir: /volume1/@docker/aufs
  Backing Filesystem: extfs
  Dirs: 625
  Dirperm1 Supported: true

grmbl99 commented 2 years ago

Looking at the docker documentation: https://docs.docker.com/storage/storagedriver/select-storage-driver/

It seems that overlay2 is only supported with ext4 or xfs as 'backing' filesystem.

squirtbrnr commented 2 years ago

I'm no expert, but reading from the official docker documentation may shed some light on this: https://docs.docker.com/storage/storagedriver/select-storage-driver/

btrfs backing file system requires the btrfs storage driver and neither can be used with anything else. However, btrfs says it "allows for advanced options" but doesn't exactly list what (maybe the additional caps?).

aufs will be deprecated in future docker releases and it is recommended users migrate to overlay2

migrating is a simple as modifying the ~~/etc/docker/daemon.json~~ (see the link below for the correct location and name of the file) file BUT doing so will make any existing image and container inaccessible and broken, so you have to back them up and recreate them after restarting the service with the new storage driver.

EDIT: See the comments here regarding editing the storage driver on synology. Seems as if the docker package or synology or both may not properly support overlay2 which is why the default is aufs except for in cases where the docker package is installed on a BTRFS volume, then the default is btrfs. https://forums.docker.com/t/overlay2-driver-problems/89374

PromoFaux commented 2 years ago

@imro2 Does it work for you when you set DNSMASQ_USER to root

What do the capability debug lines look like in /var/log/pihole-FTL.log when you set DNSMASQ_USER to root? Are capabilities magically assigned, despite aufs, as in @grmbl99's case? (I'm not sure if FTL does something different to a standard setcap or not)

imro2 commented 2 years ago

@PromoFaux yes it works with DNSMASQ_USER: root.

[2022-01-04 11:29:57.559 319M] ***************************************
[2022-01-04 11:29:57.559 319M] * Linux capability debugging enabled  *
[2022-01-04 11:29:57.559 319M] * CAP_CHOWN                (00) = PIE *
[2022-01-04 11:29:57.559 319M] * CAP_DAC_OVERRIDE         (01) = PIE *
[2022-01-04 11:29:57.559 319M] * CAP_DAC_READ_SEARCH      (02) = --- *
[2022-01-04 11:29:57.559 319M] * CAP_FOWNER               (03) = PIE *
[2022-01-04 11:29:57.559 319M] * CAP_FSETID               (04) = PIE *
[2022-01-04 11:29:57.559 319M] * CAP_KILL                 (05) = PIE *
[2022-01-04 11:29:57.559 319M] * CAP_SETGID               (06) = PIE *
[2022-01-04 11:29:57.559 319M] * CAP_SETUID               (07) = PIE *
[2022-01-04 11:29:57.559 319M] * CAP_SETPCAP              (08) = PIE *
[2022-01-04 11:29:57.559 319M] * CAP_LINUX_IMMUTABLE      (09) = --- *
[2022-01-04 11:29:57.559 319M] * CAP_NET_BIND_SERVICE     (10) = PIE *
[2022-01-04 11:29:57.559 319M] * CAP_NET_BROADCAST        (11) = --- *
[2022-01-04 11:29:57.559 319M] * CAP_NET_ADMIN            (12) = PIE *
[2022-01-04 11:29:57.559 319M] * CAP_NET_RAW              (13) = PIE *
[2022-01-04 11:29:57.559 319M] * CAP_IPC_LOCK             (14) = PIE *
[2022-01-04 11:29:57.559 319M] * CAP_IPC_OWNER            (15) = --- *
[2022-01-04 11:29:57.559 319M] * CAP_SYS_MODULE           (16) = --- *
[2022-01-04 11:29:57.559 319M] * CAP_SYS_RAWIO            (17) = --- *
[2022-01-04 11:29:57.559 319M] * CAP_SYS_CHROOT           (18) = PIE *
[2022-01-04 11:29:57.559 319M] * CAP_SYS_PTRACE           (19) = --- *
[2022-01-04 11:29:57.559 319M] * CAP_SYS_PACCT            (20) = --- *
[2022-01-04 11:29:57.559 319M] * CAP_SYS_ADMIN            (21) = --- *
[2022-01-04 11:29:57.560 319M] * CAP_SYS_BOOT             (22) = --- *
[2022-01-04 11:29:57.560 319M] * CAP_SYS_NICE             (23) = PIE *
[2022-01-04 11:29:57.560 319M] * CAP_SYS_RESOURCE         (24) = --- *
[2022-01-04 11:29:57.560 319M] * CAP_SYS_TIME             (25) = --- *
[2022-01-04 11:29:57.560 319M] * CAP_SYS_TTY_CONFIG       (26) = --- *
[2022-01-04 11:29:57.560 319M] * CAP_MKNOD                (27) = PIE *
[2022-01-04 11:29:57.560 319M] * CAP_LEASE                (28) = --- *
[2022-01-04 11:29:57.560 319M] * CAP_AUDIT_WRITE          (29) = PIE *
[2022-01-04 11:29:57.560 319M] * CAP_AUDIT_CONTROL        (30) = --- *
[2022-01-04 11:29:57.560 319M] * CAP_SETFCAP              (31) = PIE *
[2022-01-04 11:29:57.560 319M] ***************************************

I think this might be an issue with "early" adopters of Docker on Synology. I have started using it back in 2018 and kept upgrading the same system and even migrated the drives to new one, it might have latched on aufs. I will try to upgrade that tonight to btrfs and let you know what I find out.

pi-hole / docker-pi-hole