Selfhosted

Thanks for explaining the underworkings, never dug to see what happened and how it works - I see it bad

So I've found that if you use the user: option with a user: UserName it requires the container to have that UserName alsoo inside. If you do it with a UID/GID, it maps the container's default user (likely root 0) to the UID/GID you provide user: 1500:1500. For many containers it just works, for linuxserver (a group that produces containers for stuff) containers I think it biffs it - those are way jacked up. I put the containers that won't play ball in a LXC container (via Incus GUI), or for simple permission fixes I just make a permissions-fixing version of the container (runs as root, but only executes commands I provide) to fill a volume with the data that has the right permissions then load that volume into the container. Luckily jellyfin doesn't need that.

I give jellyfin read-only access (via :ro in the volumes:) to my media stuff because it doesn't need to write to it. I think it's fine if your use-case needs :rw, keep a backup (even if you :ro!).

Here's my docker-compose.yml, I gave jellyfin its own IP with macvlan. It's pretty janky and I'm still working it, but you can have jellyfin use your server's IP by deleting everything after jellyfin-nw: (but keep jellyfin-nw:!) in both the networks: section and services: section. Delete the mac: in the services: section too. In the ports: part that 10.0.1.69 would be the IP of your server (or in this case, what I declare the jellyfin container's IP to be) - it makes it so the container can only bind to the IP you provide, otherwise it can bind to anything the server has access to (as far as I understand).

And of course, I have GPU acceleration working here with some embeded Intel iGPU. Hope this helps!

#
***
NETWORKS
***
 
networks:  
  jellyfin-nw:  
    # In docker, `macvlan` gets similar stuff to 
    driver: macvlan  
    driver_opts:  
        parent: 'br0'  
    #    mode: 'l2'  
    name: 'doc0'  
    ipam:  
        config:  
          - subnet: "10.0.1.0/24"  
            gateway: "10.0.1.1"  

#
***
SERVICES
***
 
services:  
    jellyfin:  
        container_name: jellyfin  
        image: ghcr.io/jellyfin/jellyfin:latest  
        environment:  
          - TZ=America/Los_Angeles  
          - JELLYFIN_PublishedServerUrl=https://jellyfin.guzzlezone.local/  
        ports:  
          - '10.0.1.69:8096:8096/tcp'  
          - '10.0.1.69:7359:7359/udp'  
          - '10.0.1.69:1900:1900/udp'  
        devices:  
          - '/dev/dri/renderD128:/dev/dri/renderD128'  
        #  - '/dev/dri/card0:/dev/dri/card0'  
        volumes:  
          - '/mnt/ssd/jellyfin/config:/config:rw,noexec,nosuid,nodev,Z'  
          - '/mnt/cache/jellyfin/log:/config/log:rw,noexec,nosuid,nodev,Z'  
          - '/mnt/cache/jellyfin/cache:/cache:rw,noexec,nosuid,nodev,Z'  
          - '/mnt/cache/jellyfin/config-cache:/config/cache:rw,noexec,nosuid,nodev,Z'  
          # Media links below  
          - '/mnt/spinner/movies:/data/movies:ro,noexec,nosuid,nodev,z'  
          - '/mnt/spinner/shows:/data/shows:ro,noexec,nosuid,nodev,z'  
          - '/mnt/spinner/music:/data/music:ro,noexec,nosuid,nodev,z'  
        restart: unless-stopped  
        # Security stuff  
        read_only: true  
        tmpfs:  
          - /tmp:uid=2200,gid=2200,rw,noexec,nosuid,nodev  
        # mac address is 02:42 then 10.0.1.69 in hex for each # betwen the .s mapped to the :s in the mac address  
        # its how docker assigns so there will never be a mac address collision  
        mac_address: 02:42:0A:00:01:45  
        networks:  
            jellyfin-nw:  
                # Docker is pretty jacked up and can't get an IP via DHCP so manually specify it  
                ipv4_address: 10.0.1.69  
        user: 2200:2200  
        # gpu capability needs render capability, see the # for your server with `getent group render | cut -d: -f3`  
        group_add:  
          - "109"  
        security_opt:  
          - no-new-privileges:true  
        cap_drop:  
          - ALL  

Lastly thought I should add the external stuff needed for the hardware acceleration to work/get the user going:

# For jellyfin low power (LP) intel QSV stuff  
# if trouble see https://jellyfin.org/docs/general/administration/hardware-acceleration/intel/#configure-and-verify-lp-mode-on-linux  
sudo apt install -y firmware-linux-nonfree #intel-opencl-icd  
sudo mkdir -p /etc/modprobe.d  
sudo sh -c "echo 'options i915 enable_guc=2' >> /etc/modprobe.d/i915.conf"  
sudo update-initramfs -u  
sudo update-grub  

APP_NAME="jellyfin"  
APP_PID=2200  
sudo useradd -u $APP_PID $APP_NAME  

The Jellyfin user isn't added to the render group, rather the group is added to the container in the docker-compose.yml file.

To be honest, you would get frequent notifications for updates that are probably more often than just to remind you. If you're like me, you'll just end up ignoring them anyway! There are a lot of small updates to a lot of software, most often not from a security point of view but just as people develop their projects. I update every week if I can but can be a couple of weeks, in which I start to feel "guilty" so when it builds up I know I have to do it

There are lots of articles out there that say the opposite. Not about Watchtower per se, but giving a container access to the socket is generally considered to be a bad idea from a security point of view.