Missing Container (Portainer_Agent) on one of my hosts

[begunfx]

Drydock version

1.4.5

What happened?

For some reason one of my portainer agents is not appearing. It happens to be the one on my server hosting drydock controller stack.

All the other ones appear just fine.

What did you expect?

Should see a Portainer_agent for all hosts except the host running the Portainer controller stack.

Steps to reproduce

Not sure what steps to provide to reproduce this. I had already deleted the database file and recreated it from scratch. The portainer_agent is created by portainer without any kind of compose or stack.

Relevant configuration

Drydock controller stack:

services:
  drydock:
    image: codeswhat/drydock:latest
    container_name: drydock
    restart: unless-stopped
    ports:
      - "3010:3000"
    depends_on:
      socket-proxy:
        condition: service_healthy
    volumes:
      - /volume1/docker/drydock:/store
    healthcheck:
      test: curl --fail http://localhost:${DD_SERVER_PORT:-3000}/health || exit 1
      interval: 10s
      timeout: 10s
      retries: 3
      start_period: 10s
    environment:
      # --- CRON SCHEDULE ---
      - DD_WATCHER_DATAVAULT_CRON=15 */6 * * *
      - DD_WATCHER_DATAVAULT_JITTER=900000

      # --- PERMISSIONS ---
      - PUID=1000
      - PGID=1000

      # --- OTHER ---
      - TZ=America/Los_Angeles
      - DD_SESSION_SECRET=<redacted>

      # --- SECURITY SCANNING ---
      - DD_SECURITY_SCANNER=trivy
      - DD_SECURITY_SCAN_CRON=0 2 * * *
      - DD_SECURITY_BLOCK_SEVERITY=NONE
      
      # --- BASIC AUTH ---
      - DD_AUTH_BASIC_ADMIN_USER=admin
      - DD_AUTH_BASIC_ADMIN_HASH=<redacted>
      
      # --- LOCAL DATAVAULT DISCOVERY (Global Watcher) ---
      - DD_WATCHER_DATAVAULT_HOST=drydock-socket-proxy
      - DD_WATCHER_DATAVAULT_PORT=2375
      - DD_WATCHER_DATAVAULT_WATCHBYDEFAULT=true

      # --- LOCAL DATAVAULT EXECUTION (Trigger Connection) ---
      - DD_TRIGGER_DOCKER_DATAVAULT_PRUNE=true

      # --- REMOTE HOST MEDIAVAULT ---
      - DD_AGENT_MEDIAVAULT_HOST=mediavault
      - DD_AGENT_MEDIAVAULT_PORT=3010
      - DD_AGENT_MEDIAVAULT_SECRET=<redacted>

      # --- REMOTE HOST TMVAULT ---
      - DD_AGENT_TMVAULT_HOST=tmvault
      - DD_AGENT_TMVAULT_PORT=3010
      - DD_AGENT_TMVAULT_SECRET=<redacted>

      # --- REMOTE HOST SERVICEVAULT ---
      - DD_AGENT_SERVICEVAULT_HOST=servicevault
      - DD_AGENT_SERVICEVAULT_PORT=3010
      - DD_AGENT_SERVICEVAULT_SECRET=<redacted>

      # --- REMOTE HOST SERVICEVAULT2 ---
      - DD_AGENT_SERVICEVAULT2_HOST=servicevault2
      - DD_AGENT_SERVICEVAULT2_PORT=3010
      - DD_AGENT_SERVICEVAULT2_SECRET=<redacted>
      
      # --- OBSERVABILITY ---
      - DD_METRICS_PROMETHEUS_ENABLE=true

      # --- GMAIL SMTP CONFIG ---
      - DD_TRIGGER_SMTP_GMAIL_HOST=smtp.gmail.com
      - DD_TRIGGER_SMTP_GMAIL_PORT=587
      - DD_TRIGGER_SMTP_GMAIL_USER=<redacted>@gmail.com
      - DD_TRIGGER_SMTP_GMAIL_PASS=<redacted>
      - DD_TRIGGER_SMTP_GMAIL_FROM=<redacted>@gmail.com
      - DD_TRIGGER_SMTP_GMAIL_TO=<redacted>
      - DD_TRIGGER_SMTP_GMAIL_TLS_ENABLED=false
      - DD_TRIGGER_SMTP_GMAIL_MODE=batch
      
      # --- PUSHOVER CONFIG ---
      - DD_TRIGGER_PUSHOVER_MOBILE_USER=<redacted>
      - DD_TRIGGER_PUSHOVER_MOBILE_TOKEN=<redacted>

      # --- DOCKER HUB (PUBLIC/PRIVATE) ---
      - DD_REGISTRY_HUB_PUBLIC_AUTH=<redacted>
      - DD_REGISTRY_HUB_PRIVATE_AUTH=<redacted>

      # --- GITHUB CONTAINER REGISTRY (GHCR) ---
      - DD_REGISTRY_GHCR_PRIVATE_USERNAME=<redacted>
      - DD_REGISTRY_GHCR_PRIVATE_TOKEN=<redacted>

  socket-proxy:
    image: lscr.io/linuxserver/socket-proxy:latest
    container_name: drydock-socket-proxy
    restart: unless-stopped
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock:ro
    environment:
      - CONTAINERS=1
      - IMAGES=1
      - EVENTS=1
      - SERVICES=1
      - POST=1
      - DELETE=1
      - NETWORKS=1
      - VOLUMES=1
      - LOG_LEVEL=info
      - RATE_LIMIT_HTTP=100
      - RATE_LIMIT_INTERVAL=1m
    healthcheck:
      test: wget --spider http://localhost:2375/version || exit 1
      interval: 5s
      timeout: 3s
      retries: 3
      start_period: 5s
  socket-heartbeat:
    image: alpine:latest
    container_name: drydock-socket-heartbeat
    command: sh -c "sleep 300"
    restart: always

Logs

Logs do show:
3/20/2026, 3:47:08 PM
warn
watcher.docker.datavault
Cannot get a reliable tag for this image [sha256:<redacted>]
This does identify the portainer_agent on my datavault host

Installation method

Docker Compose

Docker version

24.0.1

OS / Architecture

Synology DSM

[s-b-e-n-s-o-n]

Hi @begunfx — thanks for reporting this. We found and fixed the root cause.

What's happening

Your Portainer agent was deployed by Portainer directly (not via compose), so its image reference is a raw SHA256 digest (sha256:abc123...) rather than a named tag like portainer/agent:2.x. When Docker inspects this container, the image has no RepoTags — just the digest.

Drydock's watcher has a method called resolveImageName that tries to figure out the image name and tag for each container. When it encounters a sha256: reference with no RepoTags, it was returning undefined — and that undefined caused the container to be silently filtered out of the results. It never made it to the store, so it never appeared in the UI.

The warning you saw in logs:

Cannot get a reliable tag for this image [sha256:...]

was the only indication this was happening.

The fix

We changed the behavior so containers with digest-only images are no longer dropped. The fix:

1. Falls back to RepoDigests — Docker usually provides entries like portainer/agent@sha256:abc123... even when RepoTags is empty. We now extract the image name from this.
2. Last resort fallback — if neither RepoTags nor RepoDigests has useful data, the container still appears with an "unknown" tag.
3. Update checking is gracefully skipped — since there's no semver tag to compare, Drydock won't try to check for updates, but the container will be visible in your UI.

This is fixed on the feature/v1.5-observability branch and will ship in v1.5.0. The commit is 6a6831b.

Workaround for v1.4.5

Until v1.5.0 ships, you can work around this by re-pulling the Portainer agent with an explicit tag:

docker pull portainer/agent:latest
docker stop portainer_agent
docker rm portainer_agent
# Re-create via Portainer using the tagged image

This gives the container a proper RepoTags entry so Drydock can resolve it.

[begunfx]

That doesn't make sense. Why would I still be able to see the other portainer_agents then? By that logic we shouldn't see any of the agents. Also, the workaround will not work as the portainer agent is created by portainer internally without a compose stack.

[s-b-e-n-s-o-n]

You're right to call that out — and thanks for pushing back.

This bug is not "all Portainer agents disappear." It's per-container metadata: a container is dropped only when its image comes through as digest-only (sha256:...) and Docker inspect has no RepoTags. That means other portainer_agent containers can still appear if their hosts expose tagged metadata.

So your observation (one missing, others visible) is consistent with this bug — it just means the other hosts happen to have the image stored with a proper tag reference, while this specific one doesn't.

Agreed on the workaround too — in Portainer-managed environments, manual stop/rm/recreate isn't practical since Portainer owns the agent lifecycle.

To confirm the metadata difference directly, could you run this on one missing host and one visible host?

docker inspect portainer_agent --format '{{json .Config.Image}}  RepoTags={{json .RepoTags}}  RepoDigests={{json .RepoDigests}}'

We expect the missing host to show Config.Image as a sha256:... with empty RepoTags, while the visible host has a tagged reference like portainer/agent:2.x.

The code fix (6a6831bd) keeps digest-only containers visible by falling back to RepoDigests (which Docker usually still populates even when tags are missing). This ships in v1.5.0.

[s-b-e-n-s-o-n]

This fix is now available in v1.5.0-rc.1.

docker pull ghcr.io/codeswhat/drydock:1.5.0-rc.1

[begunfx]

Still not seeing Portainer or Agent containers listing for available updates for version: 1.5.0-rc.1. Seeing the following message in the log:

2026/03/24 07:24AM 40 pid=7 hostname=480c01993355 name=drydock component=watcher.docker.datavault container=datavault_portainer_agent msg=No tags found with existing prefix: 'sha'; check your regex filters

[s-b-e-n-s-o-n]

Thanks for the follow-up — there was a second layer to this bug.

What happened in RC1

The first fix (6a6831bd) kept the container visible instead of dropping it, but the tag was set to the raw digest string (sha256:abc123...). When the watcher then tried to find newer versions, the tag candidate filter extracted prefix sha from that string, searched for registry tags starting with sha, found none, and logged the warning you're seeing.

Fix

Added an early return in the version comparison: when a container's tag is a raw digest (sha256:...) or unknown, skip tag-based version checking entirely — there's no tag to compare against. The container stays visible in the UI with a "Running by digest — no tag to compare" status instead of a confusing prefix warning.

Ships in the next RC.

[s-b-e-n-s-o-n]

Reopening — this was closed without reporter confirmation that the fix actually works. Sorry about that.

[s-b-e-n-s-o-n]

This should be fixed in v1.5.0-rc.2. Please update and let us know if this resolves the issue for you.