Quick answer

What this guide helps you do

Docker Engine 29.9.1 updates containerd to 2.4.2 with two image-transfer crash fixes. Check versions, update safely and verify containers, mounts and Jellyfin afterwards.

Jellyfin beginner path

New to Jellyfin? Follow this order.

These guides form the SmallGrid Jellyfin path: install it, fix folder access, solve empty libraries, reduce unnecessary transcoding, then choose the right mini PC.

  1. How to Reduce Jellyfin Server Power Use on Ubuntu
  2. Give Jellyfin Access to Media Folders on Ubuntu
  3. Jellyfin Library Not Showing Files? 8 Checks That Fix It
  4. Jellyfin Direct Play vs Transcoding: What Is the Difference?
  5. Best Mini PC for Jellyfin: CPU, RAM and Quick Sync Specs

Quick answer

Docker Engine 29.9.1 was released on 14 October 2026 and is now the current documented 29.x patch in Docker’s official release notes.

It updates Docker’s bundled containerd to 2.4.2, which includes fixes for two denial-of-service vulnerabilities in image-transfer paths:

  • CVE-2026-95839: pulling or importing an image through containerd’s transfer service could crash containerd when a child descriptor used the io.containerd.manifest.subject annotation with a malformed digest
  • GHSA-8647-2jxj-p2rc: an untrusted registry could return a crafted Content-Length value that crashes containerd when parallel layer fetching is enabled with concurrent_layer_fetch_buffer

Docker 29.9.1 also fixes a daemon panic involving an unreachable TLS address with the fluentd log driver and fluentd-async, image digest resolution through registry mirrors, plugin privilege lookup, and two bridge/firewalld cases.

These fixes do not prove that a particular server was compromised, and the two containerd issues do not require the Docker API to be exposed. Actual exposure depends on whether the affected image-processing path and, for GHSA-8647-2jxj-p2rc, the specified parallel-fetch configuration are in use.

For an ordinary Ubuntu home server, the sensible response is:

check Engine, containerd and Compose versions
→ record the working Docker state
→ back up Compose files, .env and application data
→ preview the package update
→ update Docker Engine packages
→ verify the daemon
→ verify containers, networks and volumes
→ test Jellyfin and media access
→ update container images separately

Updating Jellyfin, Sonarr or Radarr images does not update Docker Engine itself.


1. Check your Docker Engine version

Run:

docker version
containerd --version
docker compose version

For a compact Engine check:

docker version --format 'client={{.Client.Version}} server={{.Server.Version}}'

On Ubuntu hosts installed from Docker’s Apt repository, also inspect the package candidate:

apt-cache policy   docker-ce   docker-ce-cli   containerd.io   docker-buildx-plugin   docker-compose-plugin

If containerd is not on your shell path, use the Docker package information below rather than changing the installation merely to make this command work.

If the server is on Docker 29.x and a supported 29.9.1 package is available from the package source you intentionally use, plan the update.

Do not switch package families during a security patch. If your host uses Ubuntu’s Docker packages, an appliance repository or another distribution’s packaging, follow that source’s supported update path.


2. What the containerd fixes mean for a home server

The 29.9.1 vulnerabilities are denial-of-service issues in image pulling or importing rather than evidence that every Docker host is exploitable or compromised.

Risk depends on whether the server processes untrusted or malicious image metadata through the affected containerd paths. The crafted-registry issue also requires the documented parallel layer-fetching configuration.

Exposure is more concerning when:

  • images are pulled from registries you do not fully trust
  • automation accepts untrusted image references or imports
  • the containerd transfer service handles externally supplied image content
  • concurrent_layer_fetch_buffer is enabled for parallel layer fetching

A typical home server that pulls only deliberately selected images from trusted registries may have less exposure than an automated platform handling arbitrary images. That does not make patching unnecessary: a malformed image or registry response can still affect the local container runtime during normal image processing.

Check the images and registries your Compose projects use:

docker compose config --images
docker image ls

Treat the update as vulnerability remediation, not as proof of a local incident. Investigate compromise only when logs, image provenance or other evidence gives you a reason to do so.


3. Docker 29.9.1 also includes non-security fixes

The release is not only a containerd security update.

Docker 29.9.1 also includes fixes and changes affecting:

  • the fluentd log driver when asynchronous TLS connections fail
  • image digest resolution when a registry mirror succeeds but a later lookup fails
  • plugin privilege lookup failures
  • bridge interfaces and custom firewalld zones
  • rootless --domainname handling
  • RootlessKit 3.3.0

Most SmallGrid readers do not need to change configuration because of those fixes. They do need to confirm that the daemon, networks and important containers return normally after the package update.


4. Record the working state before patching

Capture enough information to compare before and after.

docker version
docker compose version
docker info
docker ps --format 'table {{.Names}}\t{{.Image}}\t{{.Status}}\t{{.Ports}}'
docker compose ls
docker network ls
docker volume ls
docker system df
systemctl status docker --no-pager

For restart policies:

docker inspect $(docker ps -q)   --format '{{.Name}} restart={{.HostConfig.RestartPolicy.Name}}'

For Jellyfin mounts:

docker inspect jellyfin   --format '{{range .Mounts}}{{println .Source "->" .Destination "RW=" .RW}}{{end}}'

Replace jellyfin if your container uses another name.

This gives you evidence of the known-good state before the daemon restarts.


5. Back up Compose files and persistent data

Before updating infrastructure, protect the files that rebuild the stack.

For each Compose project, preserve:

  • compose.yaml or docker-compose.yml
  • .env
  • secrets
  • bind-mounted configuration directories
  • named-volume data using an application-appropriate backup method
  • application database exports where required

Render the effective Compose configuration:

cd /path/to/compose-project
docker compose config > compose-effective-before-docker-29-9-0.yaml
docker compose config --images

Protect the rendered file if it contains secrets.

Use How to Back Up and Restore Docker Compose Services if you have not already documented how your stacks are rebuilt.


6. Check storage before updating Docker

Media servers are especially sensitive to bind mounts and host storage.

Before patching:

findmnt
df -hT
lsblk -f

For Jellyfin:

docker exec jellyfin find /media -maxdepth 3 -type f | head

Use your real container path.

If media access is already broken, fix that first. Otherwise an existing mount or permission problem can be mistaken for a Docker regression after the update.

Useful references:


7. Preview the Ubuntu package update

Refresh package metadata:

sudo apt update

Check the available versions:

apt-cache policy   docker-ce   docker-ce-cli   containerd.io   docker-buildx-plugin   docker-compose-plugin

Preview what Apt intends to do:

sudo apt-get --simulate install   docker-ce   docker-ce-cli   containerd.io   docker-buildx-plugin   docker-compose-plugin

Stop if Apt proposes unexpected removals, a repository switch or package-family replacement.

For the evergreen workflow, use How to Safely Update Docker Engine on Ubuntu.


8. Update Docker Engine

For a host installed from Docker’s official Ubuntu repository:

sudo apt install   docker-ce   docker-ce-cli   containerd.io   docker-buildx-plugin   docker-compose-plugin

Read the transaction summary before confirming.

The Docker daemon can restart during the package update, briefly interrupting containers.

Keep this maintenance window narrow. Do not combine it with:

  • an Ubuntu release upgrade
  • a Jellyfin major upgrade
  • a storage migration
  • a Compose network redesign
  • a broad application-image refresh

One moving part is much easier to diagnose than five.


9. Verify Docker after the update

Check the daemon and versions:

systemctl status docker --no-pager
docker version
containerd --version
docker compose version
docker info

Then verify the runtime objects:

docker ps --format 'table {{.Names}}\t{{.Image}}\t{{.Status}}\t{{.Ports}}'
docker network ls
docker volume ls
systemctl --failed
journalctl -u docker --since '-15 minutes' --no-pager

Confirm:

  • the Docker Server version reports 29.9.1 or a later supported patch
  • the installed containerd reports the version delivered by your package source; Docker’s 29.9.1 static-binary packaging uses 2.4.2
  • the daemon is active
  • expected containers returned
  • health checks settle
  • expected networks still exist
  • expected volumes still exist
  • published ports are reachable

Do not run docker system prune -a as part of routine security patching. Cleanup is a separate maintenance job.


10. Verify networking deliberately

Docker 29.9.1 includes bridge/firewalld fixes, so compare the post-update state rather than assuming it is fine.

Check:

docker network ls
docker inspect jellyfin   --format '{{range $name, $value := .NetworkSettings.Networks}}{{println $name}}{{end}}'

If you use a reverse proxy, confirm it can still resolve and reach the target container.

If you use custom firewalld zones or disable both iptables and ip6tables, read the 29.9.1 networking section before maintenance because its fixes are specific to those paths.


11. Verify Jellyfin and the rest of the media stack

A healthy Docker daemon does not prove the application is healthy.

For Jellyfin:

docker ps --filter name=jellyfin
docker logs --since 10m jellyfin
docker exec jellyfin find /media -maxdepth 3 -type f | head

Then verify in the UI:

  • dashboard opens
  • libraries are present
  • a known file plays
  • one intentional transcode works if used
  • hardware acceleration still works
  • remote access follows the expected path

For Sonarr and Radarr, check:

  • the UI loads
  • the download client connects
  • root folders remain available
  • completed-download import still sees the expected paths

If Docker is healthy but media is missing, investigate mounts and permissions before rolling Docker back.


12. Engine updates and container-image updates are separate jobs

This distinction is worth repeating.

Running:

docker compose pull
docker compose up -d

updates application images referenced by a Compose project.

It does not normally update:

  • Docker Engine
  • Docker CLI
  • containerd
  • Buildx
  • the Compose plugin

Likewise, patching Docker Engine does not automatically update Jellyfin, Sonarr, Radarr or other container images.

Patch the Engine first, verify it, then schedule application-image updates separately.

Use How to Update Docker Containers Safely for that second job.


What changed since Docker 29.9.0?

Docker 29.9.0, released on 8 October 2026, fixed four HTTP/2 denial-of-service vulnerabilities through its Go runtime and golang.org/x/net updates. It also included image-store, rootless and networking fixes.

Docker 29.9.1 does not replace that work. It adds the containerd 2.4.2 security fixes and the daemon, registry-mirror, plugin, networking and rootless corrections described above.

If you followed the earlier version of this guide and updated to 29.9.0, check again. A server on 29.9.0 is no longer at the latest documented 29.x patch.

The URL for this guide has deliberately been preserved so SmallGrid does not create a competing version-specific page every time Docker ships another patch.


Final checklist

  • Docker Engine and Compose versions recorded before the update.
  • Docker package source confirmed.
  • Compose files and .env backed up.
  • Persistent application data protected.
  • Running containers, networks and volumes recorded.
  • Media mounts verified before maintenance.
  • Apt transaction previewed.
  • Docker packages updated through the existing supported source.
  • Docker Server reports 29.9.1 or a later supported patch.
  • The containerd version delivered by the installed Docker package has been recorded.
  • Expected containers restarted.
  • Networks and volumes remain present.
  • Jellyfin still sees media and plays a known file.
  • Sonarr/Radarr still see their root and download paths.
  • Docker journal shows no new repeating failure.
  • Application-image updates are handled separately.

Official source



Recap

Docker Engine 29.9.1 is the current documented 29.x security patch as of 19 October 2026.

The important home-server response is controlled maintenance rather than panic: record the known-good state, back up the configuration and persistent data, patch Docker through the package source you already use, verify the daemon, networks and volumes, then prove Jellyfin and the rest of the media stack still work.

Keep Docker Engine patching separate from container-image updates. That makes failures easier to identify and keeps a routine security update from becoming an accidental platform migration.

Jellyfin guide cluster

More Jellyfin fixes and setup guides

These guides link the main Jellyfin setup, permissions, remote access, direct play, and hardware topics together.