How I Set Up Emby on Unraid

I run binhex-emby as part of my Unraid media streaming setup. This is the detailed operating note for why I use it, how I think about it, how it connects to the rest of the lab, and what I would check when it starts acting wrong.

What this container does

Emby is a second media-server option for streaming and organizing media.

The container image is binhex/arch-emby. I document that on purpose because the image tells me where updates come from, what documentation to trust, and what project probably changed if the container starts behaving differently after an update.

Service screenshot

This screenshot is intentionally public-safe. I use cropped or login-level views and leave out tokens, private URLs, API keys, passwords, internal account details, and anything that would make the lab easier to attack.

Why I use Emby

I use it for fallback, comparison, and client compatibility alongside Jellyfin.

The deeper reason I use containers for this is control. I want every service to have a defined job, defined storage, defined network exposure, and a clear recovery path. If I cannot explain why a container exists, what data it owns, and what depends on it, then the stack becomes clutter instead of infrastructure.

How I set it up

• Map media folders.
• Persist Emby config.
• Keep it isolated from Jellyfin.
• Health-check container state.

The setup pattern is always the same in spirit: the container should be disposable, but the data should not be. The app image can be pulled again. The configuration, media library, database state, workflow history, or uploaded files are the pieces that need to survive.

Unraid and Docker install shape

On Unraid, this maps to the same idea as the Docker template: pick the image, set the web UI port, map appdata for config, map the real data folders, then start the container. On Ubuntu or any normal Docker host, the same shape looks like this after replacing the placeholder paths with your own folders.

I keep Emby separate from Jellyfin so testing one media server does not overwrite the other one’s appdata.

services:
  emby:
    image: binhex/arch-emby:latest
    container_name: emby
    restart: unless-stopped
    ports:
      - "8097:8096"
    volumes:
      - /mnt/user/appdata/emby:/config
      - /mnt/user/media:/media:ro

I keep secrets out of public examples. Real passwords, VPN credentials, API keys, claim tokens, tunnel IDs, and private hostnames belong in environment files or the app UI, not in a public article.

How I use it day to day

• Test playback compatibility.
• Compare metadata behavior.
• Use as a fallback media interface.
• Keep config separate.

Day to day, I try not to treat Docker like a mystery box. I check the service from the app UI, then the container status, then logs, then storage and networking. That order keeps me from randomly restarting things when the real issue is a bad path, a dead dependency, or an expired token.

What it connects to

• media folders
• TV/mobile/browser clients
• Watchstate

This matters because most container problems are not isolated. A media request app might be healthy but unable to reach Sonarr. Sonarr might be healthy but unable to reach a downloader. A web app might be healthy but failing because the database is gone. Mapping the connections makes troubleshooting faster.

How I would hook up notifications

• Uptime Kuma HTTP monitor
• admin alerts if configured

My notification rule is simple: alert me when I need to act, not every time something makes noise. For public services, I care about uptime and response time. For automation services, I care about failed jobs and stuck queues. For sensitive services, I care about access, failed updates, and backup verification.

What I monitor

• container status
• application logs
• storage mappings
• connected app health

The minimum useful monitoring is container state plus one real application check. A container can be running while the app inside is broken, so I prefer checking the actual web endpoint, API health, or workflow behavior whenever possible.

What usually breaks first

• bad path mapping
• permissions issue
• API connection failure
• upstream app update
• network or DNS issue

When something breaks, I do not start by rebuilding the container. I first ask what changed: an image update, a config edit, a permission change, a moved folder, a full disk, a dead dependency, or an expired credential. Most Docker issues are boring once the dependencies are visible.

Backup and recovery notes

Back up appdata and any service-specific database or media path that the app depends on. The container image can be replaced; the state is what matters.

For recovery, I care about tested restores. A backup that has never been restored is only a guess. The practical goal is to know which folder, volume, database, or config file has to come back first so the service can be rebuilt without panic.

Security notes

Expose only what needs to be reachable, protect admin access, and keep tokens, providers, private URLs, and tunnel details out of public notes.

I also avoid publishing secrets in these articles. Public notes can explain the architecture, the purpose, and the operating model without exposing passwords, tokens, private hostnames, tunnel IDs, or anything that gives someone a map to attack the setup.

Bottom line

Emby earns a place in the lab when it solves a real problem and I can operate it without guessing. The point is not just having a container running. The point is knowing what it does, what depends on it, how I get notified, and how I recover it when something eventually breaks.

How I update it safely

I do not treat container updates like a blind button press. My safe update flow is: check the current container health, read what image is running, confirm backups or appdata are safe, update one service at a time when possible, then verify the web UI, logs, and any connected apps after the container comes back.

• Check whether the container is healthy before touching it.
• Back up appdata or confirm the backup path exists before risky upgrades.
• Update during a quiet window, especially for media and database-backed services.
• Verify the service after update with the UI, logs, and Uptime Kuma or a direct health check.
• If something breaks, roll back the image or restore appdata instead of guessing.

Current library scale

The media stack is not tiny anymore. The current Tower snapshot I checked shows about 645 movie video files, 246 TV show folders, about 15,900 TV/video files, and about 18,262 photo files. That scale is why the container notes matter: playback, indexing, subtitles, requests, downloads, heat, storage, and backups all start interacting.