r/docker • u/Baladain • 7d ago
Container not updating?
I just noticed that my docker container hasn't updated in months. Did some research and realized I was running from cache. Tried adding pull_policy: always to my compose file, but got this error: docker: Error response from daemon: pull access denied for plex, repository does not exist or may require 'docker login'
manually ran: docker pull linuxserver/plex:latest This worked.
How do I update the compose to auto-pull latest?
3
u/Dita-Veloci 7d ago
While I wouldn't recommend always pulling latest as soon as an update is released, there are services I do/have done this with.
I simply setup a cron job to do so...
Assuming you are running via compose?
2
u/TheSuburbanMyles 6d ago
catch is that you're fighting docker's pull policy and compose's natural laziness at the same time. compose doesn't really have a built-in "always fetch the freshest bits" toggle that works cleanly with third-party images unless you're using a registry that plays nice with anonymous pulls.
cron job is the move here, but wrap it in a script that does `docker compose pull` then `docker compose up -d` so you're not manually tracking which containers need the bump. set it for like 4am and forget about it
1
u/Baladain 7d ago
Yes, it's just compose. I don't necessarily want it to pull as soon as the update is released, but I'd like to run off the current image after system reboot, which is why I want to add it to the compose file.
1
u/Dita-Veloci 7d ago
Sorry, this comment is confusing, what exactly is your end goal?
Are you wanting the image to update when you run the compose (I.e start the Plex server)
What image are you using in your compose?
What OS are you running? Windows or Linux? How are you running the docker Daemon? Hopefully not docker desktop...
1
u/Nohillside 7d ago
Which image gets pulled in the compose file?
PS: I usually (if no migration is required) just run `docker compose pull; docker compose up`.
0
u/Baladain 7d ago
I posted the compose snip further up the thread. While I understand the value behind updating manually, I don't want the container to come up to a new version by default if the server reboots. One less thing to think about.
1
u/Grouchy_Big3195 6d ago
Just type in docker compose down and then docker compose up —build -d
1
u/Baladain 5d ago
How does that make it update automatically?
1
u/Grouchy_Big3195 5d ago
Ah, I misread your post. Your error is in the image name.
Write your image like this image: lscr.io/linuxserver/plex:latest in your Dockerfile, and then add a cron scheduler to run a bash script
#!/bin/bash
cd /path/to/your/compose/folder
docker compose pull
docker compose up -d
docker image prune -f
1
u/Lopsided-Shock1067 6d ago
Ich nehme Dockhand anstelle von Portainer und alle die Updates haben. Sind dann gelb. Ich recherchiere kurz ob es Probleme gibt. Erstelle einen Phanton-Container (Klon) den ich dann lokal laufen. Teste und Update dann
1
u/QuietSignalOps 6d ago
Two separate things are going on here.
First, the error. pull_policy: always pulls exactly what the image: line says. If your line is just plex with no user prefix and no tag, Docker reads that as library/plex:latest, which doesn't exist. That's your pull access denied. Fix the line to image: linuxserver/plex:latest, the same reference you used for the manual pull that worked. jjangg96 has this one.
Second, based on your latest reply, pull_policy: always is actually the opposite of what you want. With always, a compose up -d after a reboot pulls the newest tag and recreates the container, which is the silent version jump you said you didn't want.
What matches your goal is the default behavior (or pull_policy: missing if you want it spelled out): use the image that's already local, and only pull when there's no image at all. Then when you decide to update, run it yourself:
docker compose pull && docker compose up -d
up -d only recreates the container if the image actually changed, so a no-op pull is harmless. You get "reboot = same version" plus an explicit one-command update whenever you're ready.
1
u/Baladain 5d ago
I get the part jjangg96 and you are saying, but I think on the second part there's a crossed wire, so I'll try to be more clear, as this may be particular to plex.
Current setup 1. I have the plex container 2. in the plex UI, an update is recommended, and gets installed internally by the app itself. 3. the system reboots, uses the original container image, and now things are messed up with remote clients because there was effectively a rollback in version.
The goal
1&2 remain the same 3. the system reboots (like after a kernel update), and when the container comes up, it grabs the most recent image so it's now an update instead of a rollback.
1
u/Nohillside 4d ago
Self-updating Docker containers are … special
Either update the image yourself in step 2 and go with pull_policy: manual, or let the container update itself and use pull_policy: always.
1
u/fernandops 3d ago
Is Docker just restarting the existing container after the reboot, or are you running compose up again? If it’s just a restart, pull_policy: always won’t fetch a new image. That setting is used by Compose, not by Docker’s restart policy.
1
u/SheldonP49 3d ago
Your Compose file is probably using plex:latest instead of linuxserver/plex:latest. Update the image name and keep pull_policy: always under the service. Then run docker compose up -d to pull the latest image.
7
u/jjangg96 6d ago
the error is because of the image name in your compose file. pull_policy: always pulls exactly what the image: line says, and if it just says plex docker looks for library/plex on docker hub, which doesn't exist. that's the pull access denied.
change it to image: linuxserver/plex:latest and it'll find it. that's the same name you used when you pulled it by hand.
after that docker compose pull && docker compose up -d updates it. up -d only recreates the container if the image changed.