# nzbfast on a Synology NAS, as a Container Manager Project.
#
#   1. File Station: make a folder for nzbfast, e.g. /docker/nzbfast, and
#      THREE folders inside it named exactly: config, downloads, watch.
#   2. Put this file in /docker/nzbfast.
#   3. Container Manager -> Project -> Create. Name it nzbfast, set the
#      path to that folder, and choose the option that uses the
#      docker-compose.yml already there.
#   4. Open http://YOUR_NAS_IP:6789 and add your Usenet server in the
#      Welcome panel.
#
# There is nothing in this file you need to edit, and you do not need SSH.
#
# Step 1 is what replaces the old PUID/PGID hunt. Folders you make in File
# Station belong to you, and nzbfast adopts the owner AND group of the
# folders it is given, so downloads come out owned by you and manageable in
# File Station. Let Docker create those folders instead and they belong to
# root, nzbfast has nothing to read an owner from, and it falls back to uid
# 1000 - a user your NAS does not know, whose files you then cannot manage.
# A container cannot see the folder ABOVE a mount, so it genuinely cannot
# work this out for itself; making three folders up front is the whole fix.
#
# Full walkthrough: https://nzbfast.github.io/nzbfast/synology.html
#
# Keep the :latest tag. A container created from a version tag such as
# :1.0.3 never moves to a newer release, no matter what you do later:
# Watchtower and a manual re-pull both fetch the tag the container was
# created with.
services:
  nzbfast:
    image: nzbfast/nzbfast:latest        # searchable in Container Manager
    # Identical image on GitHub, if you prefer it:
    # image: ghcr.io/nzbfast/nzbfast:latest
    container_name: nzbfast
    restart: unless-stopped
    ports:
      - "6789:6789"
    volumes:
      - ./config:/config            # settings + index database
      # Finished files. If Sonarr or Radarr also run on this NAS, this
      # line is the one to change: downloads have to sit under the same
      # shared folder as your library, mapped to the SAME path on both
      # sides, or every import copies the whole release instead of
      # renaming it. The walkthrough has the two-minute version:
      # https://nzbfast.github.io/nzbfast/synology.html
      - ./downloads:/downloads      # finished files
      - ./watch:/watch              # drop an .nzb here to auto-download
    # Hardening. Nothing to set and nothing to read: these three blocks take
    # away powers the container has by default and does not use. The five
    # capabilities are added back by name because the container needs exactly
    # those to hand your folders to your own DSM user - it starts as root for
    # that one job and drops to your uid before the downloader itself runs.
    # Drop them all with nothing added back and the container will not start.
    cap_drop:
      - ALL
    cap_add:
      - CHOWN
      - DAC_OVERRIDE
      - FOWNER
      - SETGID
      - SETUID
    security_opt:
      - no-new-privileges:true
    # Nothing below is needed for a normal install.
    #
    # environment:
    #   # Only if you did NOT make the folders yourself, or you want the
    #   # files owned by somebody other than their owner. SSH in and run
    #   # `id your_dsm_username` to get the two numbers.
    #   - PUID=1026
    #   - PGID=100
    #   # Pick your own API key instead of the one nzbfast generates.
    #   - NZBFAST_APIKEY=change-me
    #
    # TZ is deliberately absent here: nzbfast keeps times as UTC and the
    # dashboard renders them in whatever timezone your BROWSER is in, so
    # setting it on this container changes nothing you can see.

  # Keeps nzbfast up to date. It checks nightly at 04:00 for a newer
  # nzbfast image and recreates the container when one ships. Your
  # settings and downloads survive, because they live in the folders
  # above rather than inside the container.
  #
  # Read this before you keep it: Watchtower needs the Docker socket to
  # recreate containers, and mounting /var/run/docker.sock gives this
  # container root-equivalent control of your NAS. That is a real trade,
  # convenience against handing one container broad power. If you would
  # rather not make it, delete this whole watchtower block and use the
  # DSM scheduled task at the bottom of this file instead.
  #
  # As written it is scoped to nzbfast by the name at the end of the
  # command line, so it never touches your other containers.
  watchtower:
    # The maintained fork. The original containrrr/watchtower was
    # archived, and its image has not been rebuilt since 2023.
    image: nickfedor/watchtower
    container_name: nzbfast-watchtower
    restart: unless-stopped
    environment:
      # This one DOES matter: it is what makes the schedule below 04:00
      # your time rather than 04:00 UTC. Change it to your timezone.
      - TZ=Etc/UTC
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock
    command: --cleanup --schedule "0 0 4 * * *" nzbfast

# Auto-update without the Docker socket
# ------------------------------------
# If you deleted the watchtower service, DSM can do the same job on a
# schedule and nothing needs the socket mounted:
#
#   Control Panel -> Task Scheduler -> Create -> Scheduled Task ->
#   User-defined script. Run it as root, daily, with:
#
#     cd /volume1/docker/nzbfast && docker compose pull && docker compose up -d
#
# Adjust the path to the folder holding this file. On DSM 7.1 and older
# the command is `docker-compose` (with the hyphen) rather than
# `docker compose`.