Preferred/recommended configuration for Emby Server in a Proxmox LXC?

[PaulAdams 4]

Current setup:
Intel NUC 8th gen i7
10Gbps USB-SFP+ NIC
Proxmox 8.3.5

Ubuntu 22.04 VM (2x vCPU, 8GB)
Mounted (read only) SMB shares emby_tv and emby_movies from 2 QNAP NAS devices
Docker

Emby Server container with mounts passed through

(VM was originally on ESXi 7.0u3, moved with Proxmox migration tool.)

This setup works perfectly, library scans are super quick, flawless access on the LAN via the Internet via HTTPS.

I know, I know - "if it ain't broke, don't fix it"
But I've been migrating som Photon vms running Pi-hole to Debian LXCs on Proxmox and was wondering if the current setup could be optimized, possibly removing the Docker layer?

I used the PVE Tools script to set up an LXC with Emby Server on a second NUC (10th gen i5, also 10Gbps SFP+) and added the same libraries directly in the app using the SMB path, but it was significantly slower to do a library scan for some reason.

So, does anyone have an Emby Server LXC running on Proxmox with remote libraries who could share some positive experiences or tips?

[Luke 42077]

Hi @PaulAdamslooks like there's plenty of Proxmox users here:

https://emby.media/community/index.php?/search/&q=proxmox&quick=1

I'm not sure who the best person to ask is though. Maybe @Q-Droid  or   @quickmic?

[quickmic 1703]

Yes, I run Emby in an LXC container on proxmox. There is no need to use docker and actually makes no sense to run a container in a container.

Simply use the debian 12 standard container template and install Emby server amd64.deb from here:

https://github.com/MediaBrowser/Emby.Releases/releases

Stable or beta is up to you.

If the media files are available on the host then mount the drive into the container and don't use smb or nfs. No need for this extra layer.

root@proxmox:~# cat /etc/pve/lxc/207.conf 
arch: amd64
cores: 38
cpuunits: 4096
features: nesting=1
hostname: multimedia
memory: 196608
mp0: /mnt/storage0,mp=/mnt/storage0
nameserver: 192.168.0.202
net0: name=eth0,bridge=vmbr0,gw=192.168.0.5,hwaddr=16:D3:29:2C:8B:97,ip=192.168.0.207/24,type=veth
onboot: 1
ostype: debian
rootfs: storage1:207/vm-207-disk-0.raw,size=1000G
searchdomain: rms-systems.intranet
swap: 512
root@proxmox:~# 

 

Important for performance, use an nvme/ssd as container store.

Edited April 18, 2025 by quickmic

[PaulAdams 4]

Cheers guys, I have done some empirical tests and there was a big difference in indexing performance between native SMB in Emby and passing through (RO) mounts from the PVE host (which in turn map to the same CIFS shares) - like 6+ minutes compared with 5 seconds once the initial sync was done (possibly an SMB version or dialect difference?).

Ran Debian and Ubuntu LXCs side-by-side and there was no noticable difference, went with Debian for consistency with other LXCs such as Pi-hole.

Removing the extra complexity of "docker volumes" on the old container feels nice, I couldn't recall at first how the container saw the external volumes when the VM didn't

The hosts are using NVMe and each NAS has SSD storage.

I have just now set up Trakt so I can run Emby Server instances on each of my 3 hosts for HA (I have a cron job on the docker host to recycle the container due to memory exhaustion, so my aim is to remove this hack-workaround too).

Thanks for the input, and the excellent app!

[quickmic 1703]

Well I meant, passing the drive when mediafiles are actually located on the Proxmox node on a native drives. My server also acts as a data store (Raid 5 volume). As you have a NAS, not sure it it makes a difference mounting the share inside LXC or mounting on host and passing the volume into the container.

Performance:

If you have a large media library, you might think about using a tmpfs for emby's databases. Needs some hacks, but gives an extra boost.

Here are some scripts:

mounts:

root@multimedia:~# cat /etc/fstab 
tmpfs /var/lib/emby/cache tmpfs defaults,noswap,noatime,size=96G 0 0
tmpfs /var/lib/emby/config tmpfs defaults,noswap,noatime,size=1G 0 0
tmpfs /var/lib/emby/data tmpfs defaults,noswap,noatime,size=16G 0 0
tmpfs /var/lib/emby/ffmpeg tmpfs defaults,noswap,noatime,size=1G 0 0
tmpfs /var/lib/emby/fonts tmpfs defaults,noswap,noatime,size=1G 0 0
tmpfs /var/lib/emby/localization tmpfs defaults,noswap,noatime,size=2G 0 0
tmpfs /var/lib/emby/logs tmpfs defaults,noswap,noatime,size=4G 0 0
tmpfs /var/lib/emby/plugins tmpfs defaults,noswap,noatime,size=2G 0 0
tmpfs /var/lib/emby/root tmpfs defaults,noswap,noatime,size=1G 0 0
tmpfs /var/lib/emby/sync tmpfs defaults,noswap,noatime,size=1G 0 0
tmpfs /var/lib/emby/transcoding-temp tmpfs defaults,noswap,noatime,size=64G 0 0

syncscripts:

root@multimedia:~# cat /opt/tmpfs-persistent.sh 
#!/bin/bash
rsync -ar /var/lib/emby/cache/ /var/lib/emby-persistent/cache/
rsync -ar --delete /var/lib/emby/config/ /var/lib/emby-persistent/config/
rsync -ar --delete /var/lib/emby/data/ /var/lib/emby-persistent/data/
rsync -ar --delete /var/lib/emby/ffmpeg/ /var/lib/emby-persistent/ffmpeg/
rsync -ar --delete /var/lib/emby/fonts/ /var/lib/emby-persistent/fonts/
rsync -ar --delete /var/lib/emby/localization/ /var/lib/emby-persistent/localization/
rsync -ar --delete /var/lib/emby/logs/ /var/lib/emby-persistent/logs/
rsync -ar --delete /var/lib/emby/plugins/ /var/lib/emby-persistent/plugins/
rsync -ar --delete /var/lib/emby/root/ /var/lib/emby-persistent/root/
rsync -ar --delete /var/lib/emby/sync/ /var/lib/emby-persistent/sync/
#rsync -ar --delete /var/lib/emby/transcoding-temp/ /var/lib/emby-persistent/transcoding-temp/

 

root@multimedia:~# cat /opt/persistent-tmpfs.sh 
#!/bin/bash
rsync -ar /var/lib/emby-persistent/cache/ /var/lib/emby/cache/
rsync -ar --delete /var/lib/emby-persistent/config/ /var/lib/emby/config/
rsync -ar --delete /var/lib/emby-persistent/data/ /var/lib/emby/data/
rsync -ar --delete /var/lib/emby-persistent/ffmpeg/ /var/lib/emby/ffmpeg/
rsync -ar --delete /var/lib/emby-persistent/fonts/ /var/lib/emby/fonts/
rsync -ar --delete /var/lib/emby-persistent/localization/ /var/lib/emby/localization/
rsync -ar --delete /var/lib/emby-persistent/logs/ /var/lib/emby/logs/
rsync -ar --delete /var/lib/emby-persistent/plugins/ /var/lib/emby/plugins/
rsync -ar --delete /var/lib/emby-persistent/root/ /var/lib/emby/root/
rsync -ar --delete /var/lib/emby-persistent/sync/ /var/lib/emby/sync/
#rsync -ar --delete /var/lib/emby-persistent/transcoding-temp/ /var/lib/emby/transcoding-temp/

If you have plenty of ram, you could also cache all metadata as I do. The most important folder is the "/var/lib/emby/data/" as it includes the databases.

 

Scheduler:

root@multimedia:~# cat /etc/cron.hourly/emby 
#!/bin/bash
exec /opt/tmpfs-persistent.sh

 

Systemd service:

root@multimedia:~# cat /etc/systemd/system/multi-user.target.wants/emby-server.service 
[Unit]
Description=Emby Server is a personal media server with apps on just about every device
After=network.target

[Service]
EnvironmentFile=/etc/emby-server.conf
WorkingDirectory=/opt/emby-server
ExecStartPre=/opt/persistent-tmpfs.sh
ExecStart=/opt/emby-server/bin/emby-server
ExecStopPost=/opt/tmpfs-persistent.sh
ExecStartPost=/bin/sh -c "/opt/tasks.sh &"
RestartForceExitStatus=3
User=root
TimeoutSec=0

[Install]
WantedBy=multi-user.target

The systemd service will be overwritten on each emby server update! You must patch it each time or write a systemd drop-in.

Also I run my server as root, as I have a proxy etc. Also low ports are usually blocked for users but I want my emby server listen on port 443/80 and not 8096 etc.

 

 

Edited April 18, 2025 by quickmic

[PaulAdams 4]

19 minutes ago, quickmic said:

Well I meant, passing the drive when mediafiles are actually located on the Proxmox node on a native drives. My server also acts as a data store (Raid 5 volume). As you have a NAS, not sure it it makes a difference mounting the share inside LXC or mounting on host and passing the volume into the container.

Yeah, my hosts are NUCs with just 1TB NVME local storage, and I've always assumed I would be using them as hypervisors for containers or multi-master VMs such as domain controllers I knew the NASes would be used for bulk, static data (but on SSDs for file transfer performance).

(I considered going the iSCSI route even for the VM storage but that would impact all the services too much every time a NAS gets a firmware update and needs at least 1 reboot,)

I did, however, notice a difference in indexing performance when Emby Server pointed to the UNC path as opposed to a pass-through mount.

28 minutes ago, quickmic said:

Performance:

If you have a large media library, you might think about using a tmpfs for emby's databases. Needs some hacks, but gives an extra boost.

The library isn't massive and I've not had any performance issues with playtback or indexing, but I'll bear it in mind, thanks!

34 minutes ago, quickmic said:

If you have plenty of ram, you could also cache all metadata as I do. The most important folder is the "/var/lib/emby/data/" as it includes the databases.

That's one thing a NUC doesn't have, alas - but it was something I am considering synchronizing between the various instances.

I have been mounting the NAS shares as read-only due to a bad experience when a Kodi client wiped all the media a few years ago, I wonder if it's possible to centralize the metadata (and even user playback state information) to a separate read-write share (or database)... that would be neat...