UnraidHub
An isometric NAS server with drive bays and a cooling fan sits beside a network switch, glowing shipping-container icons stacked on a highlighted platform on top.
Docker

How to Set Up Unraid Docker Containers

A practical guide to setting up Unraid Docker containers, including Docker setup, Community Applications, appdata paths, networks, and updates.

By UnraidHub Editorial · · 5 min read

Unraid packages Docker as a first-class feature of the OS rather than something you bolt on, and that changes how to set up Unraid Docker containers compared to a plain Linux box: there’s a GUI for the Docker engine, a curated app store for templates, and a storage convention (the appdata share) that most guides assume you already know. This walkthrough covers the parts that actually trip people up on a first server: enabling Docker, installing a container through Community Applications, getting path mappings right, picking a network type, and keeping things updated without breaking your configs.

Enable Docker and pick a storage backend

Docker on Unraid is off by default and lives under Settings > Docker. Flip it on and you’ll be asked how container data is stored. Historically that meant a single virtual disk image, docker.img, usually placed on the cache pool for speed, with all container data and programs living inside that one file (Unraid Docs: overview). Since Unraid 6.12, you can instead point Docker at a plain directory on a Btrfs or ZFS-formatted pool rather than a loopback image, which is simpler to manage and harder to fill by accident, since a directory just grows with the underlying filesystem instead of hitting a fixed image size.

Either way, the container’s data and programs are separate from your actual application data. Unraid uses a dedicated appdata user share to hold each container’s settings and working files, specifically so backups and migrations don’t require touching the Docker storage at all (Unraid Docs: overview). If you only back up one share on an Unraid box running containers, make it appdata.

Install containers through Community Applications

You could hand-build every container from the Docker tab’s “Add Container” form, filling in the repository string and every path yourself. Almost nobody does this for common apps. Community Applications (CA) is a plugin that adds an Apps tab to the WebGUI and functions like an app store, offering a curated catalog described by Unraid’s own docs as over 2,000 free Docker containers and plugins maintained by the community (Unraid Docs: Community Applications).

To get it running:

  1. Install the Community Applications plugin (most Unraid installs prompt for this during initial setup; if not, it’s a plugin install from the Plugins tab using the CA plugin URL).
  2. Refresh the page once installation finishes to load the full Apps interface.
  3. Search for the app you want, review its description, and click Install.

Because these templates are community-maintained rather than reviewed by Lime Technology, the docs are explicit about vetting before you click install: check the developer’s reputation, prefer apps with active support threads, and be deliberate about which of your shares, pools, or data you’re about to expose to a container you didn’t write (Unraid Docs: Community Applications). Keep the installation window open until it finishes; closing it mid-pull can leave a container half-configured.

CA opens a pre-filled template for the container. That template is where you’ll actually set the paths, ports, and variables covered below, then click Apply.

Get path mappings right

This is the step that causes the most support-forum posts. Every container needs its persistent data mapped from a path inside the container to a path on your Unraid server, and mixing these up is how people lose configs on a container update.

The convention:

  • Container path: the directory the application expects internally, almost always something like /config or /data. This is fixed by the app; you don’t choose it.
  • Host path: where that data actually lives on your array or pool, by convention /mnt/user/appdata/<container-name> for configs, and wherever your media or working files live for bulk data.

Unraid’s docs note that host paths are created automatically if they don’t exist, and that seeing folders you didn’t expect under a mount usually means a mapping is pointed somewhere you didn’t intend (Unraid Docs: managing and customizing containers). Each mapping also has an access mode, and the guidance is to use the most restrictive one that still lets the app function, meaning read-only for anything the container only needs to read, like a media library it serves but doesn’t write to.

Don’t map anything you don’t need to. A container that only needs its config directory and one media folder shouldn’t also have your entire array mounted read-write.

Choose a network type deliberately

Unraid exposes four Docker network modes, and the default isn’t always the right one:

  • Bridge: Docker’s internal network, with explicit port mapping between host and container. This is the default and the safest choice for most apps since ports are contained and conflicts are visible in the GUI.
  • Host: the container shares the server’s network stack directly, no port mapping needed, but you’re now responsible for avoiding port collisions with Unraid itself and other host-mode containers.
  • None: no network connectivity at all, for containers that only need local disk access.
  • Custom (macvlan/ipvlan): the container gets its own IP on your LAN, appearing as a distinct device. This is common for apps like Pi-hole that want a stable, dedicated address, but it’s the most advanced option to configure correctly.

One gotcha worth knowing before you hit it blind: Docker can’t run two networks on the same subnet, so switching a server between wired and wireless connections (or changing your LAN’s IP range) can force a Docker restart to sort itself out (Unraid Docs: managing and customizing containers).

For ports, only change the host-side value unless you know the application explicitly supports remapping its internal port. Changing the container-side port on an app that hardcodes it internally will just leave the app unreachable.

Variables, updates, and what to check after install

Environment variables in the CA template handle everything the app needs at runtime that isn’t a file path: timezone, PUID/PGID for file permissions, API keys, admin passwords. Use them instead of hardcoding secrets into a config file the container overwrites on every restart.

If you’re chaining containers, such as a media app that depends on a download client or a database a service needs before it will start, plan for startup order and verify it after any change to the stack. A container that starts before its dependency is reachable will often just crash-loop.

For updates, CA’s Apps tab includes an Action Center that tracks which installed containers have new versions available, along with deprecated, incompatible, or blacklisted apps (Unraid Docs: Community Applications). Because your actual data lives in the appdata share and not inside the container image, pulling an update and recreating the container is normally non-destructive as long as you didn’t change the path mappings. Unraid doesn’t natively run Docker Compose stacks through its GUI (Unraid Docs: overview), so if you’re used to docker compose up -d for multi-container stacks, expect to either use CA templates per-container or install a separate Compose management plugin from Community Applications.

Sources

  1. Unraid OS manual: running Docker containers (overview)
  2. Unraid OS manual: managing and customizing containers
  3. Unraid Docs: Community Applications
  4. techsentinel.news
#unraid #docker #homelab #community-applications#self-hosting

Related