Install Jellyfin on Synology NAS with Container Manager

Version numbers, package names and settings come from Synology's own Knowledge Center, Jellyfin's installation docs, the SynoCommunity package page and each Docker image's documentation, checked in September 2026.

Two ways to run Jellyfin on a Synology NAS

Container Manager is the more common route today and is what the rest of this guide covers first. Synology's own Knowledge Center describes the Project feature in Container Manager as the interface for running a compose.yml file without opening a terminal (kb.synology.com, Project), and Jellyfin's installation guide for Synology confirms Container Manager is what it documents rather than a package (jellyfin.org, Synology).

Setting up Container Manager

1. Open Package Center and install Container Manager. It replaced the older "Docker" package name starting with DSM 7.2; the underlying software is unchanged.
2. In File Station, create a shared folder for Docker data if one does not already exist (Container Manager creates a docker shared folder itself on first launch). Inside it, make a folder for the Jellyfin project, for example docker/jellyfin.
3. Open Container Manager → Project → Create.
4. Give the project a name, point Path at the folder from step 2, and switch the source to Create docker-compose.yml.
5. Paste in one of the compose files below, adjust the paths, and click Next, then Done.

Jellyfin's own hardware guidance notes that "many pre-built NAS devices are underpowered" for transcoding and suggests giving the container all available CPU resources and at least 4 GB of RAM (jellyfin.org, Synology) — worth keeping in mind before you commit to running several other containers alongside it on a small NAS.

The compose file: official image or linuxserver

Jellyfin's own container documentation gives jellyfin/jellyfin as the reference image, with /config, /cache and a media volume, ports 8096/tcp for the web interface and 7359/udp for auto-discovery, and bridge networking by default; host networking is only needed for DLNA (jellyfin.org, Container installation).

services:
  jellyfin:
    image: jellyfin/jellyfin:latest
    container_name: jellyfin
    user: 1000:1000
    volumes:
      - /volume1/docker/jellyfin/config:/config
      - /volume1/docker/jellyfin/cache:/cache
      - /volume1/media:/media:ro
    ports:
      - 8096:8096
      - 7359:7359/udp
    restart: unless-stopped

The official image does not read PUID/PGID environment variables. Instead, the same documentation says to set the numeric user: uid:gid line directly in the compose file to run as a non-root account instead of root (jellyfin.org, Container installation).

linuxserver/jellyfin is built differently and does use PUID/PGID, plus a TZ timezone variable, according to its own documentation (docs.linuxserver.io, jellyfin):

services:
  jellyfin:
    image: lscr.io/linuxserver/jellyfin:latest
    container_name: jellyfin
    environment:
      - PUID=1000
      - PGID=1000
      - TZ=Europe/Berlin
    volumes:
      - /volume1/docker/jellyfin/config:/config
      - /volume1/media/tvshows:/data/tvshows
      - /volume1/media/movies:/data/movies
    ports:
      - 8096:8096
      - 7359:7359/udp
    restart: unless-stopped

Either image works. The linuxserver image is convenient if you are already used to PUID/PGID from its other containers; the official image is maintained directly by the Jellyfin project.

Finding your PUID and PGID on DSM

1. Create or pick the DSM user that should own your media, for example a dedicated jellyfin user under Control Panel → User & Group.
2. Open Container Manager, go to any running container's terminal, or SSH into the NAS, and run id <username> to get the numeric UID and GID — the same lookup the linuxserver documentation points to for any host (docs.linuxserver.io, jellyfin).
3. Use those numbers for PUID/PGID (linuxserver image) or user: uid:gid (official image).

Shared folder permissions

Jellyfin only sees what the UID or account you configured can read on the host. On DSM this usually goes wrong in one of two ways:

• The shared folder's File Station → Properties → Permissions does not grant that user (or its group) at least read access to the media folder.
• The media volume is mounted :ro in the compose file (recommended, since Jellyfin has no reason to write to your library) but the config or cache path is mounted read-only by mistake, which stops the server from starting at all.

Fix permissions from Control Panel → Shared Folder, select the folder, and edit permissions for the user or group tied to your container's UID/GID, rather than editing anything inside the container.

Hardware transcoding: check your model first

/dev/dri passthrough only helps if the NAS actually has a GPU behind that device node. Add it to either compose file above:

    devices:
      - /dev/dri:/dev/dri

Not every Synology "Plus" model qualifies anymore. Models built around an Intel Celeron with integrated graphics, like the DS920+ (Celeron J4125, Intel UHD Graphics 600, HEVC encode and decode) support hardware transcoding. The DS923+, in contrast, uses an AMD embedded Ryzen R1600 with no integrated GPU at all, so there is no hardware transcoding path regardless of Docker configuration (nascompares.com, DS923+ vs DS920+).

The last row is not a hardware limit. Community reports describe Synology shipping its 2025 "x25" refresh — including the DS225+ and DS425+ — with the same J4125 chip as the DS920+, but without the i915 graphics driver DSM needs to expose Quick Sync to Docker containers, citing HEVC/AVC licensing costs as the reason (community.getchannels.com). The chip can still decode and encode video; DSM on that model just does not expose it. Community workarounds exist to restore the driver, but they run outside Synology's support and need to be redone after some updates.

Check your exact model's CPU and integrated graphics before buying or before troubleshooting a missing /dev/dri device — a "Plus" name no longer tells you which chip is inside. Once you have confirmed your model qualifies, the QSV/VA-API setup itself, the codec generation limits, and the dashboard steps are the same as on any other Docker host: see Jellyfin hardware acceleration on a NAS or mini PC for that part.

The SynoCommunity package, as an alternative to Docker

SynoCommunity publishes a native Jellyfin package outside Package Center's default sources, and it is still actively maintained: the package page lists Jellyfin v12.1-41 as its current release, last updated 15 September 2026, for DSM 7.x across 20 processor architectures, with over 50,000 downloads in the preceding 90 days at the time of that check (synocommunity.com, jellyfin package).

1. In Package Center → Settings → Package Sources, add https://packages.synocommunity.com as a source.
2. Go to the Community tab that appears, find Jellyfin, and install it.
3. Jellyfin runs under a dedicated sc-jellyfin service account. Grant that account read access to your media shared folders from Control Panel → Shared Folder, the same way you would for a Docker UID (docs.synocommunity.com, Jellyfin).
4. For hardware transcoding on Intel models, install the separate SynoCli Video Driver package, then pick Video Acceleration API (VAAPI) as the hardware acceleration method in Jellyfin's dashboard, with the device set to /dev/dri/renderD128 (docs.synocommunity.com, Jellyfin).

The SynoCommunity docs flag one thing worth knowing before any update, Docker or package: "major Jellyfin versions migrate the database forward with no downgrade path" — an older server build cannot read a database a newer one has already touched. The package creates a backup automatically before a major-version upgrade so you can roll back if something breaks (docs.synocommunity.com, Jellyfin).

Updating

Container Manager Project: open the project, use its update option in the UI, or connect over SSH and run sudo docker compose pull followed by sudo docker compose up -d inside the project folder. Pinning the image to an older tag and bringing the project back up is the rollback path if a new version misbehaves (wundertech.net, Container Manager on a Synology NAS).

SynoCommunity package: Package Center shows available updates like for any other package, and creates its pre-upgrade backup automatically for major versions, as noted above.

Either way, read the release notes for anything you are jumping over, especially across major versions, given the one-way database migration.

Pointing clients at your server

Once Jellyfin is running, clients on the same network reach it at http://<nas-ip>:8096. For access away from home, do not simply forward port 8096 to the internet without reading up on the trade-offs first — see Jellyfin remote access, done securely for the options. Quick Connect lets you sign a device in without typing a password on a remote's on-screen keyboard, covered in Jellyfin Quick Connect, explained.

FAQ

Summary

On DSM 7.2 and newer, the straightforward path is a Container Manager Project running jellyfin/jellyfin or linuxserver/jellyfin, with correctly owned shared folders for /config, /cache and your media. Hardware transcoding depends entirely on your model's chip: Intel-based models with an integrated GPU can pass /dev/dri through; recent AMD Ryzen–based Plus models cannot, and some 2025-refresh Intel models had the driver removed by Synology itself. SynoCommunity remains a maintained, non-Docker alternative with its own permissions model and its own hardware acceleration setup. Whichever route you take, update deliberately — Jellyfin's database migrations only go forward.

Sources

• Jellyfin: Synology installation guide
• Jellyfin: Container installation
• Synology Knowledge Center: Project (Container Manager)
• WunderTech: Container Manager on a Synology NAS
• LinuxServer.io: jellyfin image documentation
• Docker Hub: jellyfin/jellyfin
• SynoCommunity: Jellyfin package
• SynoCommunity docs: Jellyfin
• NAS Compares: DS923+ (AMD R1600) vs DS920+ (Intel J4125)
• Channels community forum: Synology hardware transcoding removal