I think that’s technically what these rules:
# cat /etc/cont-init.d/45-plex-hw-transcode*
#!/usr/bin/with-contenv bash
# Check to make sure the devices exists. If not, exit as there is nothing for us to do
if [ ! -e /dev/dri ] && [ ! -e /dev/dvb ]; then
exit 0
fi
FILES=$(find /dev/dri /dev/dvb -type c -print 2>/dev/null)
GROUP_COUNT=1
for i in $FILES
do
# Get the group ID for the dri or dvb device.
DEVICE_GID=$(stat -c '%g' "$i")
# Get the group name (if it exists)
CURRENT_GROUP=$(getent group "${DEVICE_GID}" | awk -F: '{print $1}')
# If it doesn't exist, create a new group name and assign it to the device GID
if [ -z "${CURRENT_GROUP}" ]; then
CURRENT_GROUP=video${GROUP_COUNT}
groupadd -g "${DEVICE_GID}" "${CURRENT_GROUP}"
fi
# If plex user isn't part of this group, add them
if [ ! $(getent group "${CURRENT_GROUP}" | grep &>/dev/null plex) ]; then
usermod -a -G "${CURRENT_GROUP}" plex
fi
GROUP_COUNT=$(($GROUP_COUNT + 1))
done
Are supposed to be doing. I’m not sure why it doesn’t work, but my guess is that it’s Qnap specific.
The reason I went with making a copy of /dev/dri is that I didn’t want to blindly change the permissions on the Qnap filesystem without knowing possible side effects. But I think theoretically you could just chown the “real” /dev/dri directory and save a few steps.
Qnap runs everything as an admin, and the Docker container runs things as a more limited user named Plex (which makes more sense, honestly), so I’d guess that doesn’t help.
Tweaking the above script to be Qnap specific is a bit out of my area of expertise, though.
It depends what you mean by named volumes.
Let’s say you had this at the end of your Docker compose file:
volumes:
- config:/config
- transcode:/transcode
- mymedia:/data/media
volumes:
config:
transcode:
mymedia:
You’d be telling Docker to create three volumes. One named “config”, one named “transcode”, and one named “mymedia”.
If you wanted to access the files, you could create a Shared Folder or SSH into the NAS under:
/share/Container/container-station-data/lib/docker/volumes
And access the files there. However, those are still linked to the container itself. Delete the container, and they go “poof”.
You can also create “external volumes” that survive the container, so to speak.
That would look like:
volumes:
- plexinc-qplex_config:/config
- plexinc-qplex_transcode:/transcode
- plexinc-qplex_mymedia:/data/media
volumes:
config:
external: true
transcode:
external: true
mymedia:
external: true
But the part that trips me up is that for an external volume, you have to manually create them first. In my mind it would be more intuitive if Docker created them if they didn’t exist, but used them if they already did, but that’s not how it works.
So via SSH you’d run something like:
docker volume create --name=plexinc-qplex_config && docker volume create --name=plexinc-qplex_transcode && docker volume create --name=plexinc-qplex_mymedia
THEN when you used “external: true” in your compose file it would use those volumes. And they’ll remain in the Docker volumes folder unless you “prune” them either via CLI or in the ContainerStation via the “Volumes” tab.
I added the container name in the second example because that’s something Docker does automatically when you create volumes in the compose file, so I just got used to doing it that way.
Theoretically if you didn’t want to manually create the volumes via CLI, you could first create the container with a compose file that has:
volumes:
- config:/config
- transcode:/transcode
- mymedia:/data/media
volumes:
config:
transcode:
mymedia:
Then, stop the container. Edit the compose file in ContainerStation (that’s another neat feature, you can add/remove/tweak lines of the compose file without having to recreate the entire thing). Then replace it with:
volumes:
- plexinc-qplex_config:/config
- plexinc-qplex_transcode:/transcode
- plexinc-qplex_mymedia:/data/media
volumes:
plexinc-qplex_config:
external: true
plexinc-qplex_transcode:
external: true
plexinc-qplex_mymedia:
external: true
Really though, for this particular Docker image you don’t really need to define any volumes. In my last revision of my Docker file this:
volumes:
- /share/Multimedia:/data/media/Multimedia:ro
- /share/Movies:/data/media/Movies:ro
- /share/plexdocker/dev/dri:/dev/dri
- /share/plexdocker/config:/config
“Mounts”/maps folders from the NAS to folders that exist within the container. The first two being my media folders, and the second two being folders I pre-setup via FileStation. One for the drivers and one for all the config data.
One reason not to do it that way is permissions, but since I created those folders with my Qnap user, and then applied the same UID/GID to the Plex user within the Docker container:
- PLEX_UID=1000
- PLEX_GID=100
It all seems to work out. There are situations where you might not want to do that. In the docs they mention:
If you bind-mount into a non-empty directory on the container, the directory’s existing contents are obscured by the bind mount. This can be beneficial, such as when you want to test a new version of your application without building a new image. However, it can also be surprising and this behavior differs from that of docker volumes.
In this case it works with the config folder because as the container is being created it’ll add the “Plex Media Server” directory and files. But there are situations where if you tried to do that and your “source” folder wasn’t setup correctly you’d have suddenly just created an empty directory within the container where configuration files it needs should be.
