Image Request: Emby Server

[karmantyu]

I'm quite new to the Daemonless project and amazed by the possibilities that can be reached with it.

I would like to kindly request adding Emby Server to the image catalog. I saw that Plex and Jellyfin are already available, so Emby would nicely round up the selection.

Emby has a native FreeBSD port and packages available here: https://github.com/MediaBrowser/Emby.Releases.
You can also find a guide to see the installation and dependencies here: https://emby.media/freebsd-server.html.

[ahze]

I've never used Emby, but since they provide a binary and it's in ports, should be straight forward to implement.

[karmantyu]

It is my main media server at home so testing the image would be a pleasure from my side.

[ahze]

Done: https://daemonless.io/images/emby/

One thing to note: the :latest tag is currently aliased to :pkg (FreeBSD quarterly packages, 4.9.3.0). The upstream binary (4.9.5.0) appears to have a transcoding issues on FreeBSD. It was generating -vn -an -sn (no streams), resulting in empty output.

I couldn't determine whether it's an Emby bug or something specific to how the binary package is built, so I've aliased :latest to :pkg for now. I'll keep an eye on it and switch back once it's resolved.

[karmantyu]

Thank You for the very fast work. I run Emby server beta in production always and never had any problem with it. The new beta [4.10.0.12] runs perfect.
The issue with the compiled container is:
Emby container crashes on FreeBSD 14.4-RELEASE: Failed to create CoreCLR

Environment

• Host OS: FreeBSD 14.4-RELEASE
• Container Engine: Podman
• Image: ghcr.io/daemonless/emby:latest

Problem Description

When trying to run the latest Emby container on a FreeBSD 14.4 host using Podman, the container initializes but immediately crashes during the s6 supervision phase when starting the Emby server.

It seems the binary inside the image expects FreeBSD 15 ABI/libraries, which causes the .NET CoreCLR to fail on a 14.4 host.

Logs

[init] Starting container initialization...
[init] Running: /etc/cont-init.d/10-usermod
[usermod] Setting up user bsd with PUID=1000 PGID=1000
[usermod] User bsd configured (uid=1000, gid=1000)
[init] Initialization complete
[init] Starting s6 supervision...
Failed to create CoreCLR, HRESULT: 0x8007FF02
[s6] Service 'emby-server' crashed (Exit: 137, Signal: 0)

Feature Request / Question

Could you please consider adding a dedicated build tag for FreeBSD 14 (e.g., :14 or :14.4), similar to how it was addressed in the Nextcloud image repository? This would allow users on the current STABLE branch of FreeBSD to utilize this native container.

[ahze]

Failed to create CoreCLR, HRESULT: 0x8007FF02.

looks like mlock issue. If running podman-compose your compose have org.freebsd.jail.allow.mlock: "true" or for podman, --annotation 'org.freebsd.jail.allow.mlock=true'and do you have atleast ocijail 0.5.0 ?

[ahze@saturn ~]$ pkg search ocijail
ocijail-0.5.1                  Experimental, proof-of-concept OCI-compatible runtime for jails
[ahze@saturn ~]$

[karmantyu]

You are right again, I missed the mlock=TRUE annotation. Importantly however for users running this image in a FreeBSD jail via Podman/Bastille, the container may require also the org.freebsd.jail.allow.suser: "true" annotation for two critical reasons:

1. Process & Signal Management: Without suser privileges, the internal s6-overlay init system cannot manage its processes or signals correctly. This causes standard shutdown signals (SIGTERM) to fail, forcing Podman to hard-kill (SIGKILL) the container after 10 seconds, which risks database corruption.
2. Hardware Transcoding (FFmpeg): The bundled FFmpeg binaries need suser permissions to access host device nodes (like /dev/dri via VA-API) for hardware-accelerated video transcoding. Without it, the ffdetect routine and hardware transcoding will fail or fall back to high CPU usage.

Would you consider please to add a note about this requirement to the documentation or the example compose file like for mlock? https://daemonless.io/images/emby/ https://github.com/daemonless/emby/pkgs/container/emby
org.freebsd.jail.allow.suser: "true"

It would be also important to mention if PUID:PGID is changed in compose.yaml, the user needs to change the rights on the config directory.
chown -R NewPUID:NewPGID /YourContainerLocation/config

Ad I saw here https://github.com/daemonless/emby/pkgs/container/emby the image 4.9.3.0 is tagged as latest.
If you have spare time, could you try to create an image tagged as beta (for example) from the https://github.com/MediaBrowser/Emby.Releases/releases/download/4.10.0.12/emby-server-freebsd14_4.10.0.12_amd64.pkg pkg?

Thank You

[ahze]

I'll work on updating docs for hardward encoding. I think we can do it without ...suser, we have examples in https://daemonless.io/images/jellyfin

I'll also look at adding a :beta tag as well.

[ahze]

added the beta tag

[karmantyu]

Thank you for the beta tag. It's fresh, up to date and running nice on FreeBSD 14.4