The bug

Firstly, thank you for UpSnap and all the work you've put in.

So while attempting to run UpSnap with a non-root user today on TrueNAS Scale 25.10.1 (Debian 12.11), I kept encountering the following error:
2026-01-10 21:52:27.002035+00:00[ERROR] 2026/01/10 16:52:27 cronjobs.go:64: socket: permission denied
...which resulted in the UI never being updated properly. Everything runs fine as root.

Further investigation led me to the UPSNAP_PING_PRIVILEGED environment variable noted in the docker-compose.yml so I first set that to false with no success. Then I set it to true and it worked, which seems wrong based on the documentation and counterintuitive:

It seems that without the UPSNAP_PING_PRIVILEGED=false, it will still check for root and use an unprivileged ping. So setting UPSNAP_PING_PRIVILEGED=false isn't 100% necessary. But the reason why I had to set it to true instead is as follows:
https://pkg.go.dev/github.com/asmpro/go-ping#readme-note-on-linux-support

Note on Linux Support:
This library attempts to send an "unprivileged" ping via UDP. On linux, this must be enabled by setting

sudo sysctl -w net.ipv4.ping_group_range="0 2147483647"
If you do not wish to do this, you can set pinger.SetPrivileged(true) and use setcap to allow your binary using go-ping to bind to raw sockets (or just run as super-user):

setcap cap_net_raw=+ep /bin/go-ping

I quickly verified that NET_RAW capability was already granted to the container (it was) and that the issue was net.ipv4.ping_group_range was not set to 0 2147483647 (it was set to 1 0).

I don't know if anyone else has run into this problem yet, but this threw me for a loop and I think some better/corrected documentation in the docker-compose.yml and Wiki needs to be made. I'll submit proposed changes shortly for that.

However, my question is this: is a behavior modification for UpSnap a good idea?

If a container is running rootless, but it has the proper NET_RAW capability, then UpSnap shouldn't be attempting to use an unprivileged UDP ping which may or may not require additional user action (either I have to sudo sysctl -w net.ipv4.ping_group_range="0 2147483647" on the host, or else I have to counterintuitively set UPSNAP_PING_PRIVILEGED=TRUE)

It seems there should be a better way to do this.

The OS that UpSnap is running on

TrueNAS Scale 25.10.1 (Debian 12.11)

Version of UpSnap

5.2.7

Your docker-compose.yml content

services:
  upsnap:
    environment:
      TZ: America/New_York
      UPSNAP_PING_PRIVILEGED: 'TRUE'
    group_add:
      - 568
    hostname: upsnap
    image: seriousm4x/upsnap:5.2.7
    network_mode: host
    platform: linux/amd64
    privileged: False
    pull_policy: missing
    restart: unless-stopped
    stdin_open: False
    tty: False
    user: '568:568'
    volumes:
      - bind:
          create_host_path: False
          propagation: rprivate
        read_only: False
        source: /mnt/MyPool/upsnap
        target: /app/pb_data
        type: bind
volumes: {}

The above docker-compose.yml is the working one on my host.

Reproduction steps

1.Run image as rootless
2.Note above described behavior

Additional information

No response