Version: 13.x

Docker

Some of these steps may not apply to your installation. Understand what they do, and ignore, or customize as necessary.

Preparation

For operating system support and service packages.

Debian Linux

Install Docker (Engine): https://docs.docker.com/engine/install/debian/

Fedora Linux

Install Docker (Engine): https://docs.docker.com/engine/install/fedora/

Extra instructions

sudo usermod -a -G docker <username>;

Re-login or restart the machine.

sudo su -;
mkdir /srv/UMS;
chcon -t svirt_sandbox_file_t /srv/UMS;
chgrp docker /srv/UMS;
chmod -R g+w /srv/UMS;

Montar el Almacenamiento al Cliente y enlacelo a ese directorio, probablemente solo de lectura mount <Videos-Share> '/srv/UMS/Videos'

Texto de ejemplo: Enlace simbólico simple a otra ruta en el sistema anfitrión puede no funcionar, ya que no habrá acceso a él desde afuera de la ruta del volumen montado por el contenedor del docker. En su lugar, intente copiar los archivos dentro de esta ubicación.

Container Setup

Mount the following volumes:

Media folder /media
Profile folder containing UMS.conf /profile

Expose/forward these ports from the host: 1044, 5001, 9001.

The following scripts accomplish that (using the fish shell):

sudo su -;
set rootDir "$HOME/.config/UMS";
mkdir -p "$rootDir/data";

docker pull universalmediaserver/ums;

docker create --name UMS \
  -p 1044:1044 -p 5001:5001 -p 9001:9001 \
  -v /srv/UMS:/root/media \
  -v "$HOME/.config/UMS":/root/.config/UMS \
  universalmediaserver/ums \
;

docker start UMS;

Investigating Problems/Issues

General

docker ps -a;
#docker attach [--no-stdin] UMS; # Still unintentionally stops container when done inspecting..
docker container logs [-f] UMS;
docker exec -it UMS /bin/sh;
docker diff UMS;

For detailed logs in the terminal: echo -e '\nlog_level=ALL' >> UMS.conf

docker cp <containerName>:/var/log/UMS/root/debug.log ./;

Mount trouble

Using Fedora CoreOS, I had access/permission denied problems trying to use bind mounts.

It may be recommended to use the Docker-managed, named-volumes capability instead, but to avoid that complexity, I found that the additional :Z as a suffix to the bind mount's descriptor option value allowed container write access to host files. :z can also be used instead, but security advice may suggest keeping resources more isolated between application/service environments, rather than shared.

Matching error messages can be seen using journalctl, so it is an SELinux problem. The solution for that would be to run chcon -Rt svirt_sandbox_file_t host_dir, but that also seems discouraged.

Strangely this is not an issue on Fedora Workstation, but I guess installing it manually added a package to deal with this. Seems to be container-selinux.