Most operating systems/environments do not need documentation for installation. This section is for those that do.
Some of these steps may not apply to your installation. Understand what they do, and ignore or customize as necessary.
Fedora Linux Preparation
For operating system support and service packages.
sudo dnf config-manager --add-repo https://download.docker.com/linux/fedora/docker-ce.repo; sudo dnf install docker-ce; sudo usermod -a -G docker <username>;
Re-login or restart the machine.
sudo systemctl start docker; sudo mkdir /srv/UMS; sudo chcon -t svirt_sandbox_file_t /srv/UMS; sudo chown core:docker /srv/UMS; chmod -R g+w /srv/UMS;
Mount storage to host and link into that directory, probably read-only.
set rootDir "/home/UMS/.config/UMS"; mkdir -p "$rootDir/data"; for file in "UMS.conf" "WEB.conf" "ffmpeg.webfilters" wget -P "$rootDir" \ "https://raw.githubusercontent.com/UniversalMediaServer/UniversalMediaServer/master/src/main/external-resources/$file" \ ; end 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;
Docker image for running UMS.
Mount following volumes and ports:
- Media folder VOLUME /media
- Profile folder containing UMS.conf VOLUME /profile
Expose/forward these ports from the host: 1044, 5001, 9001.
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 ./;
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