19 hours ago, aliaghil said:

using Docker Compose with labels, then this will fix yours.

Didn't fix mine. Do you also have something entered as the label in Docker Compose?

9 hours ago, aliaghil said:

Wondering why some of them exist there?
That means something copied them over, but not all?!

I suspect that Unraid does it for containers set up via DockerMan. You were using Compose so Unraid does not know about that type of container.

On 7/18/2026 at 5:53 AM, aliaghil said:

I also have the same problem.
I am deploying containers via Portainer, and 2 of them use the same icon. One showing, the other not.

# Namename: cloudflareservices:# CloudflareD Tunnelcloudflaretunnel:
    image: cloudflare/cloudflared:latest
    container_name: cloudflare_tunnel
    hostname: cloudflare_tunnel
    environment:
      - TUNNEL_TOKEN=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
      - PUID=99
      - PGID=100
      - TZ=Australia/Sydney
    labels:
      - net.unraid.docker.managed=dockerman
      - net.unraid.docker.icon=/mnt/user/appdata/icons/cloudflare.png
    command: tunnel --no-autoupdate run
    networks:
      - frontend
    restart: always# CloudFlare DDNS by Favonia# https://github.com/favonia/cloudflare-ddnscloudflare_ddns:
    container_name: cloudflare_ddns
    hostname: cloudflare_ddns
    image: favonia/cloudflare-ddns:latest
    environment:
      - PUID=99
      - PGID=100
      - TZ=Australia/Sydney
      - CLOUDFLARE_API_TOKEN=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
      - DOMAINS=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
      - PROXIED=false
      - IP6_PROVIDER=none
      - SHOUTRRR=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
    labels:
      - net.unraid.docker.managed=dockerman
      - net.unraid.docker.icon=/mnt/user/appdata/icons/cloudflare.png
    networks:
      - frontend
    restart: always# Networksnetworks:frontend:
    external: true

So weird.

I tried a web link like `https://raw.githubusercontent.com/prophetse7en/cloudflare-tunnel/main/cloudflare-icon.png`, same result
I tried the same PNG file from another location, without any luck.

I tried to use `net.unraid.docker.icon="file:///mnt/cache/appdata/_icons/custom-icon.png"`, still no luck.

Likely unrelated but this label is wrong - net.unraid.docker.managed=dockerman your container is not being managed by dockerman (unRAID's built in docker manager) its being managed by portainer. This label should reflect that.

3 hours ago, itimpi said:

I suspect that Unraid does it for containers set up via DockerMan. You were using Compose so Unraid does not know about that type of container.

The purpose of the net.unraid.docker.* labels was to make DockerMan aware of containers run by third party services and provide a way for them to integrate with the unRAID ui. That said there have always been some issues with the way DockerMan handles icon caching in combination with these labels.

Oh, good catch. For what it's worth, I've omitted the net.unraid.docker.managed label (and only used net.unraid.docker.icon) and it's worked up until 7.3.2.

On 7/20/2026 at 1:34 PM, trurl said:

Didn't fix mine. Do you also have something entered as the label in Docker Compose?

No, that's the compose I use.
All I did was copy their image file to that path.

On 7/20/2026 at 11:41 PM, primeval_god said:

The purpose of the net.unraid.docker.* labels was to make DockerMan aware of containers run by third party services and provide a way for them to integrate with the unRAID ui. That said there have always been some issues with the way DockerMan handles icon caching in combination with these labels.

Well, I never had issues using those labels to add a link or show a container icon in the Unraid web UI. It is weird that this is happening after updating to 7.3.2.

Headless.

Was updating from 7.3.1 to 7.3.2, seemed to work up to the reboot.

It's been 20mins, no GUI or SSH. Would I be safe to just turn the power off and hope for the best?

=====================================

Best I can tell I wasn't stuck on startup but shut down. I went and connected a monitor, console was showing login, so I did. Checking when boot;

root@Tower:~# who -b uptime -s system boot 2026-07-23 09:22 2026-07-23 09:22:20

Don't know if it was me logging into console or something else but it's working now

Edited Thursday at 08:42 AM1 day by display