Bleibt ein Container bei Watchtower auf einer alten Version, liegt die Ursache meist nicht an einer einzigen Stelle. Zuerst solltest du prüfen, ob für das Image überhaupt eine neuere Version verfügbar ist, ob der gewählte Tag zu deinem gewünschten Update-Ziel passt und ob Watchtower den Container mit den nötigen Rechten erkennen darf.
Gerade auf einem NAS mit mehreren Diensten ist es wichtig, die Prüfung geordnet aufzubauen. Erst das Image und der Tag, dann der Container selbst, danach Zugriffsrechte, Netzwerk und zuletzt die Watchtower-Konfiguration. So vermeidest du, dass du an der falschen Stelle eingreifst und einen laufenden Dienst unnötig unterbrichst.
Erst klären, ob überhaupt ein neues Image vorhanden ist
Ein Container aktualisiert sich nur dann, wenn das hinterlegte Image im Registry-Backend wirklich neuer ist als das lokal vorhandene. Nutzt du einen festen Versions-Tag wie latest, 1.0 oder 2024.12, hängt das Verhalten davon ab, ob im Repository ein neues Image unter genau diesem Tag veröffentlicht wurde.
Ein häufiger Stolperstein ist die Annahme, dass ein neues Release automatisch mit jedem Tag zusammenfällt. Viele Projekte veröffentlichen Versionen mit unterschiedlichen Tags für stabile Stände, Teststände oder Architekturvarianten. Wenn der Container auf einen Tag zeigt, der nicht mehr gepflegt wird, bleibt Watchtower ohne sichtbare Änderung.
Tags sauber einordnen
Der Tag bestimmt, welche Image-Variante Watchtower abgleicht. Das betrifft nicht nur die Version, sondern auch Architektur, Build-Variante und manchmal sogar Funktionsumfang. Ein Container mit einem sehr speziellen Tag kann deshalb korrekt laufen, aber trotzdem nie ein Update bekommen, weil es unter diesem Tag keine neue Image-Schicht gibt.
Prüfe deshalb, ob der Container auf einen absichtlich festen Stand gesetzt wurde oder ob er auf eine laufende Version wie latest oder eine serienahe Kennung zeigen soll. Für produktive NAS-Dienste ist ein fixer Tag oft sicherer, solange du Updates bewusst planst und nicht blind automatisierst.
Rechte und Zugriffsweg von Watchtower prüfen
Watchtower benötigt Zugriff auf den Docker-Dienst und auf die laufenden Container. Läuft der Dienst mit zu restriktiven Rechten, kann Watchtower das Image zwar sehen, den Container aber nicht neu starten oder nicht korrekt austauschen. Dann bleibt der Eindruck, dass keine Aktualisierung stattfindet, obwohl der eigentliche Blocker die Berechtigung ist.
Auf NAS-Systemen spielt außerdem der Socket-Zugriff eine wichtige Rolle. Wird der Docker-Socket nicht eingebunden oder nur eingeschränkt bereitgestellt, kann Watchtower keine Containerverwaltung durchführen. Besonders bei angepassten Stack-Dateien oder gehärteten Setups entsteht das Problem oft nach einem Umzug, Firmware-Update oder einer Änderung an den Benutzerrechten.
Worauf du in der Praxis achten solltest
- Der Watchtower-Container muss den Docker-Socket erreichen können.
- Der gestartete Container darf nicht durch ein zu strenges Rechtekonzept blockiert sein.
- Der betroffene Dienst sollte nicht durch andere Automationsregeln überschrieben werden.
- Nach einem NAS-Update können Container mit alten Zugriffsannahmen hängen bleiben.
Warum laufende Container trotz neuer Images stabil bleiben
Manchmal ist Watchtower technisch korrekt eingerichtet und aktualisiert trotzdem bewusst nicht. Das passiert etwa, wenn ein Container explizit ausgeschlossen wurde, wenn das Update-Fenster nicht erreicht wurde oder wenn ein Startfehler das Ersetzen verhindert. In solchen Fällen ist die fehlende Aktualisierung eher eine Schutzreaktion als ein Defekt.
Auch Umgebungsvariablen können eine Rolle spielen. Manche Container reagieren empfindlich auf geänderte Konfigurationen, Speicherpfade oder Datenbankdateien. Watchtower tauscht dann zwar das Image aus, doch der Neustart scheitert am neuen Zustand des Containers oder an einer geänderten Erwartung im Dateisystem.
Die Reihenfolge der Prüfung
Gehe am besten in dieser Reihenfolge vor: Zuerst den Image-Stand kontrollieren, dann den Tag des Containers, anschließend die Rechte von Docker und Watchtower, danach die Protokolle des betroffenen Containers und zuletzt die Startparameter. So erkennst du schnell, ob das Problem bei der Aktualisierung, beim Neustart oder bei der anschließenden Initialisierung liegt.
Wenn ein Container nach einem Update zwar neu gezogen wird, aber nicht sauber startet, ist das ein anderes Problem als ein fehlender Image-Abgleich. Dann lohnt sich ein Blick auf Volumes, Umgebungswerte und benötigte Freigaben, bevor du erneut einen Update-Zyklus auslöst.
Besondere Vorsicht bei Diensten mit Datenbestand
Für Datenbank-Container, Medienserver oder Verwaltungsdienste gilt eine strengere Vorsicht als für einfache Hilfscontainer. Ein erzwungener Tausch kann dabei nicht nur den Dienst stoppen, sondern auch Schemaänderungen, Dateirechte oder interne Migrationen anstoßen. Deshalb solltest du Updates nie nur nach dem Prinzip „neu ist besser“ laufen lassen.
Gerade bei NAS-Installationen mit wichtigen Freigaben oder laufenden Backups ist ein kontrollierter Ablauf sinnvoll. Ein Containerwechsel muss zu den gespeicherten Daten, den Volumes und den Zugriffsrechten passen. Wenn diese drei Ebenen nicht zusammenpassen, kann ein scheinbar harmloses Update mehr Aufwand erzeugen als Nutzen.
Was du nach der Prüfung erwarten solltest
Wenn Images, Tags und Rechte sauber zusammenpassen, zeigt Watchtower beim nächsten Lauf eine klare Änderung oder zumindest ein eindeutiges Verhalten in den Protokollen. Bleibt die Aktualisierung danach weiterhin aus, liegt die Ursache meist tiefer in der Containerkonfiguration, im Registry-Zugriff oder in einer bewussten Sperre durch die Startparameter.
Dann ist der nächste sinnvolle Schritt nicht ein weiterer Neustart auf Verdacht, sondern eine saubere Sicht auf den betroffenen Stack, die eingesetzten Tags und die tatsächlichen Berechtigungen des Watchtower-Containers.
,
Containerzustand und Update-Verhalten getrennt betrachten
Ein neu verfügbares Image allein reicht nicht aus, damit ein laufender Container automatisch ersetzt wird. Watchtower vergleicht zunächst die referenzierte Image-Quelle mit dem Stand auf dem Registry-Server und entscheidet dann, ob ein Pull sinnvoll ist. Bleibt der Container dennoch unverändert, lohnt ein Blick auf den tatsächlichen Laufzustand und auf den Mechanismus, mit dem der Dienst das Ersetzen ausführt. In vielen Fällen wurde das Image zwar geladen, der Neustart des Containers aber bewusst oder unbeabsichtigt verhindert.
Besonders wichtig ist die Unterscheidung zwischen einem Image-Update und einem laufenden Dienstwechsel. Ein Container kann neu gestartet werden, ohne dass die Anwendung im Inneren sichtbar anders wirkt. Umgekehrt kann ein neues Image vorhanden sein, während der alte Container weiterläuft, weil ein Abbruchschutz, ein Stopp-Fehler oder eine Sperre beim Erstellen des Ersatzcontainers greift. Wer nur auf die Versionsanzeige der Anwendung schaut, übersieht leicht den eigentlichen Engpass.
Temporäre Ausnahmen und gezielte Ausschlüsse
Manche Container werden absichtlich vom automatischen Austausch ausgenommen. Das betrifft etwa Datenbankdienste, Systeme mit manuell gepflegten Konfigurationsdateien oder Anwendungen, die an einen festen Versionsstand gebunden sind. Watchtower kann solche Container überspringen, obwohl im Umfeld ein passendes Image existiert. Auch Labels, Umgebungsvariablen oder ein abweichendes Startverhalten des Containers können dazu führen, dass der Dienst sich korrekt verhält und dennoch keinen Wechsel auslöst.
Prüfe deshalb, ob für einzelne Container eine Ausnahmeregel gesetzt wurde. Dazu gehören Filter nach Namen, Labels für ein gezieltes Opt-in oder Opt-out sowie ein Startmodus, der Updates nur beim nächsten manuellen Neustart wirksam werden lässt. In gemischten Umgebungen mit mehreren Compose-Projekten ist das besonders relevant, weil dort oft nicht alle Container gleich behandelt werden sollen.
- Label-basierte Ausschlüsse für einzelne Dienste
- Container, die nur im geplanten Wartungsfenster aktualisiert werden
- Abhängigkeiten zwischen Diensten, die einen automatischen Neustart blockieren
- Manuell gesetzte Stop- oder Restart-Vorgaben im Orchestrierungs-Setup
Registry, Authentifizierung und Image-Zugriff sauber prüfen
Nicht jedes nicht aktualisierte Bild ist öffentlich verfügbar. Bei privaten Repositories braucht Watchtower gültige Zugangsdaten, sonst bleibt der Abruf beim alten Stand hängen oder schlägt stillschweigend fehl, je nach Konfiguration und Protokollausgabe. Das betrifft auch Image-Quellen, die über ein Organisationskonto, ein Token oder ein SSO-gestütztes Login bereitgestellt werden. Ohne passenden Zugriff ist ein Update technisch nicht möglich, selbst wenn der Tag im Repository bereits weitergeführt wurde.
Daneben spielen Netzwerkpfade eine Rolle. Ein Container kann auf ein Image verweisen, das in einer internen Registry liegt, während Watchtower aus einem anderen Netzwerksegment startet oder keinen DNS-Auflösungspfad zur Registry hat. Dann erscheint von außen alles normal, aber der Pull erreicht den Zielserver nicht. Auch Rate-Limits oder temporäre Registry-Fehler führen dazu, dass der Dienst ein Update nicht abschließen kann. Wer Logs auswertet, sollte daher nicht nur nach Pull-Fehlern suchen, sondern auch auf Hinweise zu Authentifizierung, DNS, TLS und Zeitüberschreitungen achten.
Typische Stolperstellen bei privaten Repositories
Ein häufiger Irrtum besteht darin, vorhandene Logins im Docker-Host automatisch auch für Watchtower zu erwarten. Der Dienst läuft jedoch in einem eigenen Container und benötigt die passenden Credentials in seinem Zugriffskontext. Ebenso wichtig ist die Frage, welches Konto auf welches Repository zugreifen darf. Ein Token mit Leserechten für ein Projekt reicht unter Umständen nicht für alle Images, die in unterschiedlichen Namensräumen liegen.
- Prüfen, ob die Registry öffentlich oder geschützt ist.
- Verifizieren, ob Watchtower die nötigen Zugangsdaten erhält.
- DNS- und Netzwerkkonnektivität zwischen Watchtower und Registry testen.
- Auf Ablaufdaten von Tokens, Passwörtern oder Zertifikaten achten.
- Fehler im Log nicht nur beim Pull, sondern auch beim Auth-Handshake suchen.
Startparameter und Update-Strategie des Dienstes kontrollieren
Auch die Art, wie Watchtower gestartet wurde, beeinflusst das Ergebnis. Manche Installationen arbeiten mit einem reinen Monitoring-Modus, andere mit einem festen Zeitplan, wieder andere reagieren nur auf bestimmte Labels oder auf einen expliziten Trigger. Ist der Aktualisierungsmodus nicht passend gewählt, beobachtet der Container zwar neue Images, nimmt aber keinen Tausch vor. Dasselbe gilt für Zeitfenster, in denen Updates bewusst aufgeschoben werden, etwa um Lastspitzen zu vermeiden oder Wartungsregeln einzuhalten.
Ein weiterer Punkt sind Neustartregeln und Abhängigkeiten im Docker-Setup. Wird ein Zielcontainer zwar beendet, aber der Ersatz kann wegen blockierter Ports, fehlender Volumes oder kollidierender Netzwerknamen nicht gestartet werden, bleibt der alte Zustand erhalten oder der Dienst fällt in einen Fehlerzustand. Dann ist das Image zwar vorhanden, die laufende Instanz aber nicht erfolgreich ersetzt. Ein Blick auf Compose-Dateien, Compose-Overrides und die vorhandenen Restart-Policies hilft dabei, solche Blockaden zu erkennen.
Praktische Kontrolle der Konfiguration
Bei einer sauberen Prüfung steht nicht nur der Watchtower-Container im Mittelpunkt, sondern die gesamte Kette aus Registry, Startparametern und Zielcontainern. Sinnvoll ist ein Abgleich zwischen der tatsächlich laufenden Konfiguration und dem gewünschten Aktualisierungsverhalten. So lässt sich schnell erkennen, ob der Dienst ausschließlich beobachten soll, ob nur markierte Container berücksichtigt werden oder ob ein festes Intervall gerade gar nicht aktiv ist.
Gerade bei Systemen mit mehreren Projekten lohnt es sich, die Konfiguration nach Gruppen zu betrachten. Dann wird sichtbar, ob ein einzelner Dienst bewusst ausgenommen wurde oder ob ein allgemeiner Fehler alle Updates verhindert. Wer zusätzlich die Ereignisse beim Neustart prüft, erkennt oft schon daran, ob der Austausch an einem fehlenden Mount, einem Portkonflikt oder an einer Einschränkung im Startbefehl scheitert.
Häufige Fragen
Wie prüfe ich zuerst, ob überhaupt ein neues Image verfügbar ist?
Vergleiche das im Dienst konfigurierte Tag mit dem Bild, das im Registry tatsächlich bereitsteht. Wichtig ist dabei, ob ein Tag nur weitergeschrieben wurde oder ob ein neuer, eindeutig anderer Tag existiert.
Warum zieht ein laufender Dienst nicht automatisch das frischeste Image?
Ein laufender Container bleibt zunächst auf seinem gestarteten Image, bis ein Update ausgelöst wird. Zusätzlich kann ein Pull wegen Tag-Strategie, Zugriffsrechten oder lokaler Zwischenspeicher-Effekte ausbleiben.
Welche Rolle spielen Tags bei der Update-Erkennung?
Tags bestimmen, auf welches Bild Watchtower achtet. Ein festes Versions-Tag ist klarer als ein unscharfer Marker wie „latest“, weil sich damit Änderungen besser nachvollziehen lassen.
Warum ist ein Tag mit Versionsnummer oft robuster als „latest“?
Ein Versions-Tag zeigt eindeutig, welche Ausgabe gemeint ist, und reduziert Missverständnisse bei Update-Läufen. „latest“ kann zwar bequem sein, ist aber für die Fehlersuche oft weniger transparent.
Welche Rechte braucht Watchtower für den Zugriff auf Images?
Der Dienst muss das Registry-Image lesen und den Docker-Daemon ansprechen dürfen. Fehlen Registry-Zugangsdaten oder ausreichende Socket-Rechte, bleibt der Abruf oft ohne sichtbare Aktualisierung.
Wie erkenne ich Probleme mit der Registry-Anmeldung?
Prüfe, ob der verwendete Account das gewünschte Repository lesen darf und ob die Zugangsdaten im richtigen Kontext hinterlegt sind. Auch ein abgelaufenes Token oder ein falscher Registry-Pfad kann den Abruf verhindern.
Kann ein lokaler Cache den Update-Vorgang beeinflussen?
Ja, ein vorhandenes Image auf dem Host kann dazu führen, dass ein Wechsel nicht sofort auffällt. Dann lohnt sich ein Blick auf Bild-IDs, Pull-Ergebnisse und den tatsächlichen Start eines neuen Containers.
Welche Bedeutung haben Container-Namen und Compose-Dateien?
Sie bestimmen, welcher Dienst überwacht und ersetzt wird. Ein falsch benannter Service oder ein abweichender Projektname kann dazu führen, dass Watchtower den falschen Container betrachtet.
Warum sollte ich Datencontainer und Zustandsdienste vorsichtig behandeln?
Dienste mit persistenten Daten reagieren empfindlicher auf Neustarts als reine Hilfscontainer. Vor einem Austausch sollte klar sein, wo Konfiguration und Daten liegen und ob das neue Image dazu kompatibel ist.
Welche Logs sind für die Diagnose am hilfreichsten?
Hilfreich sind die Watchtower-Ausgabe, die Docker-Ereignisse und die Logs des betroffenen Dienstes nach dem Neustart. Zusammen zeigen sie, ob ein Pull stattfand, ob ein Container ersetzt wurde und ob der neue Start sauber verlief.
Woran sehe ich, dass die Prüfung erfolgreich war?
Nach einem korrekten Ablauf passt die laufende Version zum erwarteten Image und der Dienst startet sauber mit dem neuen Container. Danach sollten keine weiteren Fehler im Pull- oder Startprozess auftauchen.
Fazit
Für eine saubere Aktualisierung müssen Image, Tag und Zugriffsrechte zusammenpassen. Wer zusätzlich die Logs prüft und Dienste mit Datenbestand mit Bedacht behandelt, findet die Ursache für ausbleibende Updates meist schnell. So lässt sich der Ablauf nachvollziehbar stabilisieren.