Mount Options

^{Is it possible to edit the default mount options for shared folders?}

^{I have a docker container running emby (media browser), but the emby config folder (which can get really large) is pointed to a shared folder. Unfortunately, emby includes it's own version of ffmpeg, which sits in this config folder. I've been trying to figure out why transcoding won't work, and I suspect it's because shared folders in OMV, by default, are mounted noexec... hence ffmpeg refuses to work}

^{So I want to be able to mount the shared folder without the noexec option.}

Zitat von subzero79

Well, depends on the image i guess, because i pulled the official one docker pull emby/embyserver and the ffmpeg is inside the container in /opt/ffmpeg, i just tested and just in case moved the config folder to a default ext4 one with noexec and there was not an issue playing content from the webinterface.

I'm not sure which version of the official docker build you've been using, but the one I use puts the configurations in a volume /config, which of course, you can map wherever you like on the host system. I was originally hosting it in /etc/emby, but it can get surprisingly large and my OS drive isn't very big. So I moved it to a shared folder. This works, and the web interface will still continue to play content. But it won't transcode because ffmpeg won't execute. I can't say for certain that this is the issue... but I moved the config directory back to /etc/emby and transcoding immediately started working.

I considered a whole range of options, but in the end decided to just stick with keeping it in /etc/emby, and just increasing the size of my OS drive.

I did spend some time playing with the emby plugin, and it seems to work quite nicely. But I generally prefer using docker, at least for certain applications... particularly one like emby. Docker allows me to put some controls around the amount of resources the application uses. My NAS has a fairly limited CPU, so transcoding can slow it down somewhat. Docker allows me to minimise the impact on the host system.

Zitat von subzero79

I also tested transcoding and worked well. As I say the ffmpeg is inside the container (at least in in my docker the official one)

I understand that ffmpeg is inside the container, but is that a volume that sits on the host system in a folder mounted with noexec?

If so, then that basically means that Docker ignores the underlying file system and will allow you to execute a binary that's on a filesystem mounted as 'noexec'. That would seem strange to me. But then it's not the first time Docker has surprised me.

By default, Docker stores containers in /var/lib/docker, which on openmediavault will be on the same hard drive as the base operating system. As a generally rule, all the executables inside the container should work because they are essentially on the same file system as any executables on the host system.

The problem occurs when you create an image with volumes that you map to a mounted file share. For example, I created an Emby container with a volume called /config, and mapped it to /media/[UUID]/Emby on the host. Therefore, any executables stored in the directory /config are, on the host, stored on a file system mounted as noexec. I was a bit bored at work, so I tested this with a basic debian container. And sure enough, Docker won't run these executables.

I'm guessing the reason why transcoding works in your case, is because the container you are using is storing ffmpeg somewhere in /opt. Looking through the init scripts, it looks like there might be some kind of runtime option to specify where ffmpeg sits.

Sorry if that sounds a bit convoluted... it's taken a little bit of time for me to work out in my own head