Tur0k 148 Posted November 14, 2025 Posted November 14, 2025 On 11/11/2025 at 9:55 PM, guunter said: CasaOS is like training wheels for people new to docker it has an app store and then form like GUI for setting the variables for it. Since you're already using portainer I wouldn't switch to it. Once you get used to docker compose you'll never want to go back. I use to run lxcs in proxmox but it's annoying for migrations because the they have to be stopped vs a VM can be live migrated. Also way easier to do proper smb mounts. I know you can do it with lxcs if you make it privileged but I wanted then isolated from host. Yes, everything On 11/11/2025 at 9:55 PM, guunter said: CasaOS is like training wheels for people new to docker it has an app store and then form like GUI for setting the variables for it. Since you're already using portainer I wouldn't switch to it. Once you get used to docker compose you'll never want to go back. I use to run lxcs in proxmox but it's annoying for migrations because the they have to be stopped vs a VM can be live migrated. Also way easier to do proper smb mounts. I know you can do it with lxcs if you make it privileged but I wanted then isolated from host. Agreed about the limitation of LXCs and migrations. I actually figured out how to keep the LXC unprivileged and get my NFS shares accessible on the LXC. I actually mount the NFS shares on the host and then pass them through to the LXC as a mount point.that made it so in some cases I don’t have to open NFS ports to my truenas vm from untrusted networks and the data passes through the LXC to the PVE host to the NFS share on the back plane (as it were). I also figured out how to use vGPU sharing capabilities to share the GPU to multiple LXCs at the same time (my research indicated this wasn’t possible with VMs). I actually am moving all my docker containers to docker compose files as this makes config backup easier in the event of a complete rebuild. I actually have a project to host my own git repository and start cataloging my configs there instead.
mikeraburn 71 Posted November 14, 2025 Posted November 14, 2025 On 11/12/2025 at 12:46 PM, mikeraburn said: I prefer Casa OS is "Docker for Dummies", like me! Point and click I looked at Zima OS and that is overkill for me. I meant TrueNas was overkill and over my head! 1
dgrigo 35 Posted November 17, 2025 Posted November 17, 2025 (edited) I have as question on docker tags,https://hub.docker.com/r/emby/embyserver/ I see latest and beta, as i have used docker pull emby/embyserver:latest ,that means I will get stable only? or beta too? I dont see any stable there, Just version numbers , beta and latest Thanks in advance Edited November 17, 2025 by dgrigo
mikeraburn 71 Posted November 17, 2025 Posted November 17, 2025 I just did a clean install of ZimaOs lastnight and 4.9.1.90 is the latest. I updated it through the Emby Docker app. I do like ZimaOs better than CasaOs\Zorin18 so far
Q-Droid 1024 Posted November 17, 2025 Posted November 17, 2025 (edited) 34 minutes ago, dgrigo said: I have as question on docker tags,https://hub.docker.com/r/emby/embyserver/ I see latest and beta, as i have used docker pull emby/embyserver:latest ,that means I will get stable only? or beta too? I dont see any stable there, Just version numbers , beta and latest Thanks in advance You can expect the latest tag to reference the newest stable release and the beta tag to reference the newest beta release. There can be delays between the Emby software releases and the image builds on Docker hub so a lag is not unusual. Compare the image digest hash value on Docker Hub to find/verify which numbered releases are referenced by the latest and beta tags. Edited November 17, 2025 by Q-Droid 1
Tur0k 148 Posted November 27, 2025 Posted November 27, 2025 (edited) On 11/13/2025 at 7:54 PM, mikeraburn said: I meant TrueNas was overkill and over my head! For most people Truenas is more than you need. if you are not running ISCSI and do not have a great deal of familiarity with enterprise SAN/NAS architecture you are better off doing something simpler. Even I was a little worried when they moved from a FreeBSD Unix underlying OS over to Linux. I had heard many horror stories. I was so worried i waited until October of this year before making the jump. I read all the documentation, and have been lucky enough to sprinkle in jus the right amount of enterprise gear (ECC memory and motherboard support, and a good enterprise HBA) as well as selecting the right type of hard drives (PMR (AKA CMR) drives instead of SMR. Honestly, I think Truenas went in the right direction with their SCALE build. For me the only things I really need from my NAS are NAS things though (ZFS/RAID/mass storage configuration support, NFS, and Samba support (integrated with M$ AD authentication and authorization). I hear good things about unraid for storage management simplicity, app and service integration, and overall friendliness. Edited November 27, 2025 by Tur0k
Tur0k 148 Posted November 27, 2025 Posted November 27, 2025 (edited) On 11/17/2025 at 12:23 PM, dgrigo said: I have as question on docker tags,https://hub.docker.com/r/emby/embyserver/ I see latest and beta, as i have used docker pull emby/embyserver:latest ,that means I will get stable only? or beta too? I dont see any stable there, Just version numbers , beta and latest Thanks in advance My experience is as Q-Droid noted. when using the ":latest" tag you get the latest stable build. all the numbered tags are beta versions. Edited November 27, 2025 by Tur0k 1
Betonhaus 18 Posted February 7 Posted February 7 Does this seem like it's set up fine? I keep having issues with transcoding emby: image: emby/embyserver container_name: embyserver network_mode: host # Enable DLNA and Wake-on-Lan environment: - UID=1000 - GID=1002 - GIDLIST=993 - TZ=America/Edmonton volumes: - /mnt/docker/emby:/config - /mnt/pool/media:/mnt/media devices: - /dev/dri:/dev/dri restart: unless-stopped $ fastfetch .... redacted .',:clooo: .:looooo:. -------------- .;looooooooc .oooooooooo' OS: Ubuntu 24.04.3 LTS (Noble Numbat) x86_64 .;looooool:,''. :ooooooooooc Host: X99-D3 ;looool;. 'oooooooooo, Kernel: Linux 6.8.0-94-generic ;clool' .cooooooc. ,, Uptime: 6 days, 23 hours, 21 mins ... ...... .:oo, Packages: 1104 (dpkg) .;clol:,. .loooo' Shell: bash 5.2.21 :ooooooooo, 'ooool Terminal: /dev/pts/0 'ooooooooooo. loooo. CPU: Intel(R) Xeon(R) E5-2696 v3 (36) @ 3.80 GHz 'ooooooooool coooo. GPU 1: Intel Arc A380 @ 2.45 GHz [Discrete] ,loooooooc. .loooo. GPU 2: Intel Arc A310 @ 2.45 GHz [Discrete] .,;;;'. ;ooooc Memory: 9.63 GiB / 125.69 GiB (8%) ... ,ooool. Swap: 2.25 MiB / 8.00 GiB (0%) .cooooc. ..',,'. .cooo. Disk (/): 237.73 GiB / 456.35 GiB (52%) - ext4 ;ooooo:. ;oooooooc. :l. Disk (/mnt/backup): 118.44 GiB / 915.82 GiB (13%) - ext4 .coooooc,.. coooooooooo. Disk (/mnt/dsk/1): 10.58 TiB / 12.63 TiB (84%) - ext4 .:ooooooolc:. .ooooooooooo' Disk (/mnt/dsk/2): 10.25 TiB / 12.63 TiB (81%) - ext4 .':loooooo; ,oooooooooc Disk (/mnt/dsk/3): 10.70 TiB / 12.63 TiB (85%) - ext4 ..';::c' .;loooo:' Disk (/mnt/dsk/4): 10.76 TiB / 12.63 TiB (85%) - ext4 Disk (/mnt/dsk/5): 12.14 TiB / 14.44 TiB (84%) - ext4 Disk (/mnt/dsk/6): 12.10 TiB / 14.44 TiB (84%) - ext4 Disk (/mnt/games): 28.00 KiB / 219.00 GiB (0%) - ext4 Disk (/mnt/wrk): 68.48 GiB / 953.40 GiB (7%) - xfs If i disable subtitle extraction then access through the web app doesn't work, but if I enable subtitle extraction then devices like the Google TV shit the bed and the Emby Client for windows doesn't play subtitles
Q-Droid 1024 Posted February 8 Posted February 8 Your compose looks okay, HW detection and ffmpeg logs could show specific problems. But I see that you have another thread to troubleshoot the playback issues so you might as well continue over there since it doesn't appear to be a problem specific to Docker. One thing though - the transcoding temp path is going to default to your /config volume. So the type and size of storage used for /mnt/docker/emby can affect transcoding. In fact it can affect all of Emby.
Betonhaus 18 Posted February 8 Posted February 8 3 hours ago, Q-Droid said: Your compose looks okay, HW detection and ffmpeg logs could show specific problems. But I see that you have another thread to troubleshoot the playback issues so you might as well continue over there since it doesn't appear to be a problem specific to Docker. One thing though - the transcoding temp path is going to default to your /config volume. So the type and size of storage used for /mnt/docker/emby can affect transcoding. In fact it can affect all of Emby. I have my docker config folders on a m.2 nvme ssd. though I'm trying to troubleshoot if the transcoding issues is some sort of docker quirk so I'm setting up a baremetal install and set transcoding to /dev/shm
Q-Droid 1024 Posted February 8 Posted February 8 22 minutes ago, Betonhaus said: I have my docker config folders on a m.2 nvme ssd. though I'm trying to troubleshoot if the transcoding issues is some sort of docker quirk so I'm setting up a baremetal install and set transcoding to /dev/shm Having those on NVMe is pretty much ideal. The only limiter I can think of would be size if the transcoding temp usage gets big enough. As long as the config and transcoding paths are not on network storage you should be fine. Using HDD for config works but the latency can be noticeable for metadata cache and DB requests, more so for bigger libraries.
arpanrec 0 Posted February 19 Posted February 19 Has the docker tags been changed from https://emby.media/docker-server.html I couldn't get `4.10.0.3` in https://hub.docker.com/r/emby/embyserver_arm64v8/tags, then i noticed `https://hub.docker.com/r/emby/embyserver/tags` has a ```4.10.0.3 docker pull emby/embyserver:4.10.0.3 linux/amd64 linux/arm/v7 linux/arm64 ``` Is it official now?
alucryd 332 Posted February 21 Posted February 21 Yes it is, you can switch to this new multi-platform image on all 3 of our supported architectures. Beta only for now, but the next stable release will also be a multi-platform image.
AKSkinz 10 Posted May 16 Posted May 16 Please let me know if this is the wrong thread for this question. I am in the process of trying to downsize my electrical footprint so I have invested in a NAS to take the place of the couple of pcs I have running different services. It is time to move Emby to the NAS but I'm decided to start fresh and not deal with migrating the current setup to it. So, I have Emby running in Docker on a Ugreen NAS (DXP4800+). Everything seems to be working so far but I can't figure out how to add a new media location without having to recreate the container. I was reading about an ".embydockervolumes" file but I don't see the file anywhere. Any direction on how to add a new media location without starting over every time would be appreciated.
Q-Droid 1024 Posted May 16 Posted May 16 Recreating the container is how you update for new image releases. It's a trivial event. Making additions to the volume mappings don't affect the current config. But if you're concerned with adding media locations then map the common base path from which you branch out your media structure. Unless you're dealing with multiple/different mount points for each location which in that case you just add the mapping to a new container.
AKSkinz 10 Posted May 17 Posted May 17 I figured it out. The guide I followed to get Emby running included Portainer which caused the "edit" button to be greyed out in Docker itself. I found the editor for the stack within Portainer which allowed me to update it correctly.
Mikoyan 15 Posted May 21 Posted May 21 Hello again. I am unable to run images beyond 4.10.0.9 beta on Kubernetes due to the following: s6-rmrf: fatal: unable to remove /var/run: Read-only file system s6-overlay-suexec: fatal: child failed with exit code 111 4.10.0.11 added s6-overlay 3.2.2.0 to the image (not present in 4.10.0.9), but the image is missing /run and /var/run directories. s6-overlay's preinit fails trying to create the /var/run → /run symlink. Confirmed by inspecting both images directly — 4.10.0.9 has no /package/admin/ at all, 4.10.0.11 has s6-overlay 3.2.2.0. Neither image has /run or /var/run. The s6-overlay install in the Dockerfile likely needs to also create those directories or symlink them properly. Why was this change made and is there a change in how I need to set up my kubernetes spec file?
bonorenof 1 Posted May 22 Posted May 22 Got also some problems with s6-overlay when upgrading to the latest stable 4.9.5.0 on QNAP QTS 5. I'm getting that error: S6-overlay-suexec: fatal: can only run as pid 1 4.9.3.0 is working fine.
alucryd 332 Posted May 22 Posted May 22 23 hours ago, Mikoyan said: Hello again. I am unable to run images beyond 4.10.0.9 beta on Kubernetes due to the following: s6-rmrf: fatal: unable to remove /var/run: Read-only file system s6-overlay-suexec: fatal: child failed with exit code 111 4.10.0.11 added s6-overlay 3.2.2.0 to the image (not present in 4.10.0.9), but the image is missing /run and /var/run directories. s6-overlay's preinit fails trying to create the /var/run → /run symlink. Confirmed by inspecting both images directly — 4.10.0.9 has no /package/admin/ at all, 4.10.0.11 has s6-overlay 3.2.2.0. Neither image has /run or /var/run. The s6-overlay install in the Dockerfile likely needs to also create those directories or symlink them properly. Why was this change made and is there a change in how I need to set up my kubernetes spec file? s6 v3 has an env variable to cope with read-only filesystems, can you try adding S6_READ_ONLY_ROOT=1 to your env variables? I'll bake it in our image, it shouldn't hurt even if filesystem is readable.
alucryd 332 Posted May 22 Posted May 22 5 hours ago, bonorenof said: Got also some problems with s6-overlay when upgrading to the latest stable 4.9.5.0 on QNAP QTS 5. I'm getting that error: S6-overlay-suexec: fatal: can only run as pid 1 4.9.3.0 is working fine. Did you change any setting when creating the container? Works fine here using all defaults.
bonorenof 1 Posted May 22 Posted May 22 @alucrydAfter looking into it, the culprit was a parameter on my service in docker-compose: "init: true". It spawns tini process as PID 1 instead of the real service in order to properly manage SIGTERM signals. s6-overlay seems to not tolerate this anymore on newer versions. It works fine now without that option, thanks. 1
Mikoyan 15 Posted May 24 Posted May 24 On 5/22/2026 at 3:03 PM, alucryd said: s6 v3 has an env variable to cope with read-only filesystems, can you try adding S6_READ_ONLY_ROOT=1 to your env variables? I'll bake it in our image, it shouldn't hurt even if filesystem is readable. I added the variable to the deployment and still getting the same error: /package/admin/s6-overlay/libexec/preinit: info: read-only root │ │ /package/admin/s6-overlay/libexec/preinit: info: writable /run. Checking for executability. │ │ /package/admin/s6-overlay/libexec/preinit: notice: /var/run is not a symlink to /run, fixing it │ │ s6-rmrf: fatal: unable to remove /var/run: Read-only file system │ │ s6-overlay-suexec: fatal: child failed with exit code 111
VirtualM 2 Posted May 25 Posted May 25 Same here on a kubernetes install: /package/admin/s6-overlay/libexec/preinit: notice: /var/run is not a symlink to /run, fixing it s6-rmrf: fatal: unable to remove /var/run: Read-only file system s6-overlay-suexec: fatal: child failed with exit code 111 I've tried the env var, mounting /var and /run as emptydir then making the symlink with an initcontainer (lrwxrwxrwx 1 root root 4 May 25 08:04 run -> /run), changing the privileges of the pod but nothing helped. It always complains about the symlink.
alucryd 332 Posted Tuesday at 10:32 PM Posted Tuesday at 10:32 PM Thanks for the testing. I pushed an updated beta image, this one preemptively creates an empty /run and a symlink in /var/run. Kubernetes is supposed to mount a tmpfs at /run, but s6 will still refuse to start if it's world writable and owned by root. If that happens, you can set S6_YES_I_WANT_A_WORLD_WRITABLE_RUN_BECAUSE_KUBERNETES=1 in your environment. I can't bake that one in our image though, as it's a security risk to do so outside of kubernetes.
VirtualM 2 Posted Wednesday at 05:20 PM Posted Wednesday at 05:20 PM 18 hours ago, alucryd said: Thanks for the testing. I pushed an updated beta image, this one preemptively creates an empty /run and a symlink in /var/run. Kubernetes is supposed to mount a tmpfs at /run, but s6 will still refuse to start if it's world writable and owned by root. If that happens, you can set S6_YES_I_WANT_A_WORLD_WRITABLE_RUN_BECAUSE_KUBERNETES=1 in your environment. I can't bake that one in our image though, as it's a security risk to do so outside of kubernetes. 4.10.0.13 Works without any errors. No other env vars need to be set or folders to mount. Thank you! s6-rc: info: service s6rc-oneshot-runner: starting s6-rc: info: service s6rc-oneshot-runner successfully started s6-rc: info: service fix-attrs: starting s6-rc: info: service fix-attrs successfully started s6-rc: info: service legacy-cont-init: starting s6-rc: info: service legacy-cont-init successfully started s6-rc: info: service legacy-services: starting services-up: info: copying legacy longrun emby-server (no readiness notification) s6-rc: info: service legacy-services successfully started 2
Recommended Posts
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now