Reply to thread

Message: [QUOTE="Bombastus, post: 91430, member: 2178"] Restarting a Plex Docker container does not necessarily update its server software, even when a newer release is available. Some configurations download Plex during startup, while others keep running the version supplied inside the image. You can restart the server all afternoon and still have the wrong update method selected. The container comes back, your movies play, and nothing about the installed server version has changed. A working library gives you little evidence about whether [B][URL='https://goldmidi.com/community/threads/plex-pushes-fixes-for-media-server-and-desktop-flaws.76841/']Plex security fixes for media servers[/URL][/B] have reached your installation. Before another restart, check which image you use and what its startup settings actually request. [HEADING=2]The latest tag does not promise a startup update[/HEADING] Plex’s own public and beta image tags check for an appropriate server release when the container starts, including after a restart. An internet connection is needed for that download. The official image’s latest tag ships with Plex already installed. Updating that installation means pulling a newer image and recreating the container from it. The beta tag also depends on account eligibility. If the server isn't signed in, or its account lacks Plex Pass, Plex’s official image restricts its startup check to public releases. LinuxServer adds another setting called VERSION. With VERSION=docker, the server version comes from the image; VERSION=public requests a public Plex release during startup. The image tag and this environment variable control different things. For example, a LinuxServer image tagged latest can still use VERSION=public. A startup download changes Plex without replacing its container image, leaving you with separate application and image versions to check. [HEADING=2]A skipped update can be deliberate[/HEADING] A LinuxServer container running with a read-only filesystem cannot use its normal runtime updater. Explicitly running the container as a non-root user also disables that updater. Both restrictions are checked before the script considers your requested version. Suppose you keep the filesystem read-only and change VERSION=docker to VERSION=latest, expecting a restart to fetch Plex. The updater still skips the download. Even with a working connection. You can retain the restriction and update through a replacement image containing the required Plex release. You don't need to make the container writable just to install it. The startup log distinguishes this case from a download problem. A message about unsupported runtime updates points to the container’s operating mode. Checking DNS or changing release channels won't fix a download the script deliberately never attempted. A different message can identify a missing preferences file or account token. For a previously configured server, an unexpectedly empty /config mount could explain that result. It deserves inspection before you treat the container as a fresh installation. On a new LinuxServer setup, a skipped first update can be expected. The updater needs saved account information before continuing. Once you’ve signed in through the web interface, a restart lets it try again. The updater also exits successfully after certain failures, including a failed package download. Plex can start normally and still be running the older release. [B]An apparently successful restart[/B] is not proof that the package was installed. [HEADING=2]Edited settings need a newly created container[/HEADING] Saving a new VERSION value in Compose doesn't change the existing container. Running docker compose restart does not apply changes to environment variables, so your edited VERSION value can remain absent from the container you just restarted. Consider a writable container whose file now specifies VERSION=public, but which was created with VERSION=docker. Restarting keeps its original environment. The old instruction still tells the updater to skip its check, despite what the file on your screen says. Compose applies changed configuration when you run docker compose up -d plex, assuming your service is named plex. It recreates the affected container as needed. Use the actual service name if yours differs. When updating through the image, docker compose pull plex fetches the image referenced by your configuration. Follow it with the up command so the running service uses that image. A download alone leaves the existing container running. A configuration pinned to a specific old image tag will keep requesting that tag. Likewise, a LinuxServer VERSION value naming a particular Plex release requests that release rather than the current public one. Before recreating anything, confirm that the existing server data remains mounted at /config and keep the same media mappings. Compose preserves mounted volumes during ordinary recreation, but pointing the replacement at a different directory supplies different data. After startup, compare the server version shown in Plex with the version you intended to install. Keep the image identity separate from that check. An image label describes the packaged build, while a startup download can change the Plex application running inside it. [/QUOTE]

Name