Necessary comfyui models not installed for webui

[bjj]

harbor.comfyui  | got prompt
harbor.comfyui  | Failed to validate prompt for output 9:
harbor.comfyui  | * UNETLoader 12:
harbor.comfyui  |   - Value not in list: unet_name: 'flux1-dev.safetensors' not in []
harbor.comfyui  | * DualCLIPLoader 11:
harbor.comfyui  |   - Value not in list: clip_name1: 't5xxl_fp16.safetensors' not in []
harbor.comfyui  |   - Value not in list: clip_name2: 'clip_l.safetensors' not in []
harbor.comfyui  | * VAELoader 10:
harbor.comfyui  |   - Value not in list: vae_name: 'ae.safetensors' not in []
harbor.comfyui  | Output will be ignored

To work through this, I manually exported the "ComfyUI Workflow" JSON provided by harbor and dragged it into comfyui to try to satisfy the dependencies. It's not directly possible. For example, ae.safetensors installed through the model manager in comfyui is FLUX1/ae.safetensors. I assume the others will be similar (e.g. t5). There isn't a direct flux1-dev.safetensors in the model list.

[av]

Thanks for another report 👍

Harbor pre-configures comfyui container to run a provisioning script:
https://github.com/av/harbor/blob/main/profiles/default.env#L268-L269

It should theoretically download necessary models as well as pre-install the default workflow for WebUI, however it's also entirely possible that the configuration drifted since the initial setup and something is misaligned (first start logs should help seeing that). I'll do a "from scratch" setup tests over the weekend

[bjj]

I can confirm that the provisioning script ran. Here are the two copies of t5xxl on my system:

root@4ceeaaa86d13:/var/log# find / -name t5xxl_fp16.safetensors
/workspace/ComfyUI/models/text_encoders/t5/t5xxl_fp16.safetensors
/workspace/storage/stable_diffusion/models/clip/t5xxl_fp16.safetensors

So it looks like maybe the comfyui container was meant to have a symlink to /workspae/storage?

[bjj]

If I run /opt/ai-dock/storage_monitor/bin/storage-monitor it makes symlinks, which made me realize that there appear to be two different comfyui installations in this container, one at /opt/ComfyUI and one in /workspace/ComfyUI. The storage-manager script made links in /opt/ComfyUI but the instance that seems to be running (based on logs and what models are found) is the one in /workspace/ComfyUI. The link targets are established by /opt/ai-dock/storage_monitor/etc/mappings.sh. If I modify that to point to /workspace, I get the necessary links. However the provisioned model is flux1-schnell.safetensors and not flux1-dev.safetensors (the model name appears in the JSON and as a setting in webui; I don't know which one matters).

At this point, though, whether I submit through the comfyui gui or via webui, the queue depth goes up and it seems to hang forever. If I hit "load default" in the comfyui UI, I can render an image.

[av]

Ok, I got to the testing of the setup from scratch and noted a few issues that I missed previously:

• The initial download is even lengthier than I remember it - I think that interrupting it might be the reason initial start didn't work for you, added a note above "Starting" docs on that
• HF_TOKEN was used in the default provisioning to decide between dev/schnell FLUX versions, whereas Open WebUI config was hardcoded to dev. I don't want to make having a token an explicit requirement or a choice for the first-time users, so fixed everything to default to schnell that'll function without the token
• Open WebUI configuration has to be correct at the moment of start, otherwise it's not possible to submit an update via the UI, I updated provisioning script and default workflow to be aligned with missing HF_TOKEN, both will now default to schnell model
• QoL: added ./comfyui/workspace to the searched locations for harbor find (to lookup files easier), also all workspaces (including comfyui) are now listed with harbor size

two different comfyui installations

If I recall correctly, for the ai-dock images, the one in the /opt is the one bundled within the container, and /workspace is a mirror of that + overrides from host, it's a bit convoluted but helps working with restrictions from some cloud providers. I think that the duplication happened because of importing another workflow after the initial one, that defines t5xxl as a separate text encoder model

---

I think the main fix here was to ensure that provisioning works without HF_TOKEN (and doesn't result in discrepancy between ComfyUI and Open WebUI configs). It's currently in main and will go live with the next Harbor release a bit later today

[av]

Released in v0.2.25