2 minutes ago, chris smashe said:

Thanks. Im back up now.

You are welcome, enjoy

On 2/14/2025 at 9:16 AM, bubo said:

I was not specific enough.  What I'm requesting is an additional parameter besides the Base Directory option.  I'm already using the base directory option in the new template.  The behavior of the base directory option by itself is to have the Output folder in the same base directory as the Inputs (checkpoints/loras/embeddings/etc).  Many people put their inputs in a SSD to facilitate load times, and some of them may not want to have their generated images output to the same SSD due to size and repeated write concerns.

 

ComfyUI allows for the separation of the Output Folder from the Base Directory folder via the --output-directory command line flag, but in order to utilize that flag to put the Output folder anywhere besides the Base Directory folder in the current Docker template requires an additional field to allow the user to specify where the Output folder resides in the array.  As shown in my screenshot, it's not difficult to get it working.  However, I think that many users would prefer having that field added as part of the default Docker installation, and the corresponding --output-directory command line flag incorporated into the docker instead of  needing to be manually entered into the COMFY_CMDLINE_EXTRA field. 

 

I've looked more into this and decided not to add a new environment variable with features similar to those of an existing one.

 

I understand that some users might want to do this. I prefer to document the process for such users because it is already possible to achieve this by mounting a new path and extending the command line (as you have done).

There is a new section on GitHub's README to provide this information: "Specifying alternate folder location (ex: --output_directory) with BASE_DIRECTORY"

 

 

On 2/15/2025 at 12:48 PM, martial said:

Following up

1) comfy_extras should stay within run/ComfyUI; it is is not expected to be within basedir

2) the mikey_nodes custom node is using a variable that does not work with basedir. I have proposed a PR to them that should fix it, we have to wait for them to fix it for a fully functional option. If you are willing to manually replace the python script in the custom_nodes folder, here are the details to get it working (you only need the two first changes in the file) https://github.com/bash-j/mikey_nodes/pull/45 Another option is to copy the content of comfy_extras into basedir until mikey nodes (and potential others are fixed to reflect the use of basedir

 

Thanks for the attention to detail and submitting that PR.  I saw it was merged, I was able to uninstall then remove the extra directory in basedir and able to re-install the node just fine!
You asked for a workflow earlier here is my current one I'm working with.  I pretty much exclusively make images for my TTRPG games, its got a latent upscaler and face detailer all in there with things like Ollama prompt enhancement, controlnet, ipadapter LUTs and such.  Thanks again for the work keeping this container up to date!

TTRPG-workflow.json

1 hour ago, SeldomNosePicker said:

Thanks for the attention to detail and submitting that PR.  I saw it was merged, I was able to uninstall then remove the extra directory in basedir and able to re-install the node just fine!
You asked for a workflow earlier here is my current one I'm working with.  I pretty much exclusively make images for my TTRPG games, its got a latent upscaler and face detailer all in there with things like Ollama prompt enhancement, controlnet, ipadapter LUTs and such.  Thanks again for the work keeping this container up to date!

TTRPG-workflow.json 303.72 kB · 0 downloads

They merged and improved it by fixing the overall solution and keeping backward compatibility.

 

Thanks for sharing that workflow. I will enjoy testing it and learning from it.

Here is one of my fun ones. It is a variation on AlexLai's AtomixFlux (v1.0) workflow and gives me great 4k x 2k results

https://geekier.smmall.cloud/MTc0MDI4MjU4Njk2Mg

 

 

 

I'm new to comfyui but having a lot of fun and greatly appreciate all your hard work making this available in unraid.

 

I've only been using comfyui for about 3 days and it was working and I'm learning a lot but today when I try and run the docker it fails and gives the following error in my log:

== Upgrading pip
!! ERROR: Pip upgrade failed
!! Exiting script (ID: 56)
!! ERROR: subscript failed
!! Exiting script (ID: 1)

I tried mv mnt to mnt.old but it didn't reinstall.

 

Thank you!

7 hours ago, bellyup said:

I'm new to comfyui but having a lot of fun and greatly appreciate all your hard work making this available in unraid.

 

I've only been using comfyui for about 3 days and it was working and I'm learning a lot but today when I try and run the docker it fails and gives the following error in my log:

== Upgrading pip
!! ERROR: Pip upgrade failed
!! Exiting script (ID: 56)
!! ERROR: subscript failed
!! Exiting script (ID: 1)

I tried mv mnt to mnt.old but it didn't reinstall.

 

Thank you!

Hi, there are a couple of things that I would be curious to check:

1. you said you tried to "mv mnt mnt.old" but did not reinstall; does this mean it could not write in mnt or you had the same error?

2. could you share a more extended log and maybe the directories in your "appdata/comfyui-nvidia" ?

 

 

I took a better look at this when I got home from work.

The mv mnt to mnt.old changed the user from nobody to root, I changed it back to nobody (via the shares tab) and its reinstalling now.

 

You are awesome, I'm PMing you a thanks also. 😃

51 minutes ago, bellyup said:

I took a better look at this when I got home from work.

The mv mnt to mnt.old changed the user from nobody to root, I changed it back to nobody (via the shares tab) and its reinstalling now.

 

 

 

Interesting behavior. The tool starts as 1024:1024 but should drop down to WANTED_UID and WANTED_GID (100:99) right after it starts.

I thought I added a check to confirm that it could write in the run and basedir folders before attempting to do so. I will double-check.

 

You said you installed it a few days ago, so it should be the latest version of the script... okay I am now curious

 

 

 

Edited March 14, 20251 yr by martial

I've been struggling with the

!! ERROR: Pip upgrade failed
!! Exiting script (ID: 56)
!! ERROR: subscript failed
!! Exiting script (ID: 1)

problem for the past 3 days also.

"The mv mnt to mnt.old changed the user from nobody to root, I changed it back to nobody (via the shares tab) and its reinstalling now." comment made me double check. Apparently when i chmod 777 the folders so I can use them in windows (Boo, that's bad! Boo!) it changes users which screws everything up. I am glad I checked here again (been to this thread about 3 or 4 times the past few days).

 

Thank You for the answer!

Edited March 14, 20251 yr by accelerating-revaluation2023
Thanks

16 hours ago, accelerating-revaluation2023 said:

I've been struggling with the

!! ERROR: Pip upgrade failed
!! Exiting script (ID: 56)
!! ERROR: subscript failed
!! Exiting script (ID: 1)

problem for the past 3 days also.

"The mv mnt to mnt.old changed the user from nobody to root, I changed it back to nobody (via the shares tab) and its reinstalling now." comment made me double check. Apparently when i chmod 777 the folders so I can use them in windows (Boo, that's bad! Boo!) it changes users which screws everything up. I am glad I checked here again (been to this thread about 3 or 4 times the past few days).

 

Thank You for the answer!

 

It sounds like I need to have a check so that I can output this error in the logs if it happens, a "pip" error is not very useful

Added https://github.com/mmartial/ComfyUI-Nvidia-Docker/issues/28

Edited March 14, 20251 yr by martial

Wanted to add that I also received

error: externally-managed-environment × This environment is externally managed ╰─> To install Python packages system-wide, try apt install python3-xyz, where xyz is the package you are trying to install. If you wish to install a non-Debian-packaged Python package, create a virtual environment using python3 -m venv path/to/venv. Then use path/to/venv/bin/python and path/to/venv/bin/pip. Make sure you have python3-full installed. If you wish to install a non-Debian packaged Python application, it may be easiest to use pipx install xyz, which will manage a virtual environment for you. Make sure you have pipx installed. See /usr/share/doc/python3.11/README.venv for more information. note: If you believe this is a mistake, please contact your Python installation or OS distribution provider. You can override this, at the risk of breaking your Python installation or OS, by passing --break-system-packages. hint: See PEP 668 for the detailed specification.

at the top of the logs and I was just too dumb to realize what it was talking about.

12 hours ago, accelerating-revaluation2023 said:

Wanted to add that I also received

error: externally-managed-environment × This environment is externally managed ╰─> To install Python packages system-wide, try apt install python3-xyz, where xyz is the package you are trying to install. If you wish to install a non-Debian-packaged Python package, create a virtual environment using python3 -m venv path/to/venv. Then use path/to/venv/bin/python and path/to/venv/bin/pip. Make sure you have python3-full installed. If you wish to install a non-Debian packaged Python application, it may be easiest to use pipx install xyz, which will manage a virtual environment for you. Make sure you have pipx installed. See /usr/share/doc/python3.11/README.venv for more information. note: If you believe this is a mistake, please contact your Python installation or OS distribution provider. You can override this, at the risk of breaking your Python installation or OS, by passing --break-system-packages. hint: See PEP 668 for the detailed specification.

at the top of the logs and I was just too dumb to realize what it was talking about.

 

Did you install anything in Ubuntu that would be Python-related using apt?

 

The container is designed to run by creating a virtual environment (a place for Python to place its packages) that is in the "run" folder (namely "venv").

 

The recommended way to install packages is through the "Manager," part of the WebUI provided by ComfyUI.

 

What happened before you saw this error?

 

11 hours ago, martial said:

 

~

 

Recreating my issue:

1. Install from the Unraid App page
2. Once up and running I loaded a random workflow (Hephaistos_Tensor1.1_basicWF) and then "Install missing custom nodes"
3. Restart from the webui, refresh. Everything working still.
4. Stop container from Unraid Docker page and start again. Everything working.
5. Stop container.
6. The unraid plugin (not sure of the name offhand or it's baked in now without a plugin) let's me change permissions onthe basedir and mnt folders within comfyui-nvidia to read/write for owner, group, and other. Still shows owner as 'nobody'.
7. Start container. automatically stops with the error messages previously listed.

It's on me for not realizing a UI chmod would cause some hiccups. My current situation is everything is working, so there's that. My current setup I set up a seperate unraid share not in appdata (mainly to move to a larger drive for all the models), and it still works even after giving r/w to owner, group, and other.

Edited March 16, 20251 yr by accelerating-revaluation2023

7 hours ago, accelerating-revaluation2023 said:

Recreating my issue:

1. Install from the Unraid App page
2. Once up and running I loaded a random workflow (Hephaistos_Tensor1.1_basicWF) and then "Install missing custom nodes"
3. Restart from the webui, refresh. Everything working still.
4. Stop container from Unraid Docker page and start again. Everything working.
5. Stop container.
6. The unraid plugin (not sure of the name offhand or it's baked in now without a plugin) let's me change permissions onthe basedir and mnt folders within comfyui-nvidia to read/write for owner, group, and other. Still shows owner as 'nobody'.
7. Start container. automatically stops with the error messages previously listed.

It's on me for not realizing a UI chmod would cause some hiccups. My current situation is everything is working, so there's that. My current setup I set up a seperate unraid share not in appdata (mainly to move to a larger drive for all the models), and it still works even after giving r/w to owner, group, and other.

 

Happy to read that you got it back running.

 

I added a check option (in a dev branch) to confirm if the proper user did not own any "created" folders at container startup.

The issue will not help if people change the permissions of "run" or "basedir" themselves, so I have to think about this further.

I could add a "force_chmod" option but it is likely going to be slow and still would not fix the "run" and "basedir" mounts

 

Edited March 16, 20251 yr by martial

@bellyup @accelerating-revaluation2023

 

I have a new beta out, and I hope it will fix your problem.

To use it, you would need to change the tag of the container you are using from `latest` to `latest-beta`

The whole container tag would be: mmartial/comfyui-nvidia-docker:latest-beta

 

This new version adds checks to confirm at start time that the folders are owned by the proper uid/gid

 

I also added a "FORCE_CHOWN" (must set to a value like "yes" to enable) environment variable (add to your template).

This will perform a "chown" (change ownership) on every sub-folders within "run" and "basedir" at container start time.

Since it can not change the "run" and "basedir" (they are the mount points) it will exit in error for those, but at least the error will be more useful.

 

On 3/17/2025 at 10:37 PM, martial said:

@bellyup @accelerating-revaluation2023

 

I have a new beta out, and I hope it will fix your problem.

To use it, you would need to change the tag of the container you are using from `latest` to `latest-beta`

The whole container tag would be: mmartial/comfyui-nvidia-docker:latest-beta

 

This new version adds checks to confirm at start time that the folders are owned by the proper uid/gid

 

I also added a "FORCE_CHOWN" (must set to a value like "yes" to enable) environment variable (add to your template).

This will perform a "chown" (change ownership) on every sub-folders within "run" and "basedir" at container start time.

Since it can not change the "run" and "basedir" (they are the mount points) it will exit in error for those, but at least the error will be more useful.

 

 

So far, my testing has not shown any issues.

Updating Comfy had me do an extra restart because the WebUI is now installed from the "requirements.txt" but the "FORCE_CHOWN" and the new GL/Vulkan changes requested appear to work.

 

Unless I hear otherwise, I expect a new release to follow.

FYSA "20250320" release is complete.

 

### 20250320

- Added CUDA 12.6.3 image, which will be the new latest as of the next release

- Added checks for directory ownership

- Added FORCE_CHOWN environment variable -- used to force change directory ownership as the comfy user during script startup (this process might be slow). This option was added to support users who mount the run and basedir folders onto other hosts which might not respect the UID/GID of the comfy user. (defaults to "yes" the updated Unraid template)

- Added libEGL/Vulkan ICD loaders and libraries, including extension to the Windows usage section related to this addition

 

IMPORTANT: the next release will change the "latest" to use 12.6.3 

This will likely force a few custom nodes "try fix" as detailed in https://github.com/mmartial/ComfyUI-Nvidia-Docker?tab=readme-ov-file#about-latest-tag

 

I have manually changed my tag to use 12.6.3. With about 200 custom nodes, I had to "Try fix" about 40 (a manual click each time). This will only be needed when I change the "latest" base image.

 

Those updates are helpful to support the new features added to CUDA.

I note that this also forces a new PyTorch update (my install was old enough that I was still on 2.5; this got me to 2.6). The older "venv" is renamed in the "run" folder, and as long as you do not need anything from it later, it is safe to delete.

 

 

 

Edited March 20, 20251 yr by martial

Hi Team, I was made aware the container was not listed in CA anymore.

 

Fixed: syntax error in XML

Edited April 29, 20251 yr by martial

2 hours ago, martial said:

Hi Team, I was made aware the container was not listed in CA anymore.

Investigating

Now is listed but ...

--gpus all 'mmartial/comfyui-nvidia-docker:ubuntu24_cuda12.8'

Unable to find image 'mmartial/comfyui-nvidia-docker:ubuntu24_cuda12.8' locally
docker: Error response from daemon: manifest for mmartial/comfyui-nvidia-docker:ubuntu24_cuda12.8 not found: manifest unknown: manifest unknown.

1 minute ago, dreaz said:

Now is listed but ...

--gpus all 'mmartial/comfyui-nvidia-docker:ubuntu24_cuda12.8'

Unable to find image 'mmartial/comfyui-nvidia-docker:ubuntu24_cuda12.8' locally
docker: Error response from daemon: manifest for mmartial/comfyui-nvidia-docker:ubuntu24_cuda12.8 not found: manifest unknown: manifest unknown.

I apologize, it should have been with -latest at the end of the tag.

I just fixed the template.

 

It should be fixed in as soon as Unraid re-aggregate it or you can manually add -latest to the end of the container name

Btw, if you are going for 12,8 on a Blackwell series, you will need to add a new file in your run folder; please see the README.md for which file to place there

 

I am a little bit noob when it comes to unraid dockers. My docker image size is 50GB. As I am installing this docker, I see it filling up even though I created a separate share for the models env variable. What size of a docker file is required for the initial setup? Thanks for the guidance.

On 5/2/2025 at 10:09 AM, war1000 said:

I am a little bit noob when it comes to unraid dockers. My docker image size is 50GB. As I am installing this docker, I see it filling up even though I created a separate share for the models env variable. What size of a docker file is required for the initial setup? Thanks for the guidance.

 

short: 

Thanks for reporting this, I investigated and will need to figure out how to move the pip cache and tmp pip content.

When I do the shift, the next time you update and restart the container, that content will end up in "run" too (easier and safer)

 

long:

It is going to depend on which base image you use but the image itself is about 10GB.

Most of the content goes in the run and basedir variables that should be set to use external locations.

 

The image size will never change, but the container (the running version of the image) might, although the majority of data goes in run and basedir so it should be very light.

 

If you get a terminal on your Unraid, 
 

docker image ls
## will show the image size

docker container ls
## will show the containers running

docker ps -a --size
## will show all the container usage
# in my case: ComfyUI-Nvidia-Docker   9.88GB (virtual 21.5GB)
# the virtual size is the image itself + the writeable layers

docker diff ComfyUI-Nvidia-Docker
## will show the difference between the image and the writeable layers
# the 10GB extra in my case are the package cache + tmp content which can be removed
# /tmp/pip-* and /home/comfy/.cache/pip
# note that the "nvidia" content is added by the container runtime to provide access to the GPU

 

Edited May 3, 20251 yr by martial

On 5/2/2025 at 10:09 AM, war1000 said:

I am a little bit noob when it comes to unraid dockers. My docker image size is 50GB. As I am installing this docker, I see it filling up even though I created a separate share for the models env variable. What size of a docker file is required for the initial setup? Thanks for the guidance.

 

I have made a new release (20250503) that addresses the above and created an issue on GitHub to document the process (https://github.com/mmartial/ComfyUI-Nvidia-Docker/issues/46)

In my tests the containers only added 4GB of storage due to pip caching but if you are in a docker disk image, storing as much content outside of it might be beneficial.

 

The proposed solution is a manual one as it depends on your setup.

To trigger those changes manually create a pip_cache and tmp folder inside the "run directory" location as detailed in https://github.com/mmartial/ComfyUI-Nvidia-Docker?tab=readme-ov-file#57-runpip_cache-and-runtmp

 

The defaults set in the template is /mnt/user/appdata/comfyui-nvidia/mnt

so from a terminal:
 

cd /mnt/user/appdata/comfyui-nvidia/mnt
mkdir tmp pip_cache
chown 99:100 tmp pip_cache

 

 

Small additions: Please clean the content of those folders (not the folders themselves) once in a while to avoid pip always preferring the cached content.

cd /mnt/user/appdata/comfyui-nvidia/mnt
rm -rf tmp/* pip_cache/*

 

Edited May 4, 20251 yr by martial

Just now, martial said:

 

I have made a new release (20250503) that addresses the above.

 

 

I will just add that my reasoning for not making this the default is that this is likely useful in specific cases where the docker container disk is a disk image, but if you were to use a "data root" (ie a folder) to store the content, it might not be an issue as those are expected to be "temporary" files (the python cache and its sidecar files)

 

Please see https://www.gkr.one/blg-20241022-unraid#1bfc678a0f6980da8ecde3be4f6b7f6e for details on "data root"

 

In my case, if I restart a new the container on a Ubuntu system (from the command line using "docker run --rm"), I start from a fresh image, not an already existing one, as such no cache/temp content exists, but that is not how Unraid does this.

 

Note that depending on your setup, the content in "appdata" might also part of a backup and those 4GB of temporary content will be backed up as well.

 

Hi,

I am having issues with getting this container to launch. I'm running on Unraid 7.0.0 with a GTX 1080.

I think I followed the directions in the readme for 10XX series cards (I assume that the two "PREINSTALL_TORCH" related items were to be set as additional variables in the template?). I also have tried this with both cuda12.8 and the recommended cuda12.6.3 options.

Below are my logs (the first launch said something about PyTorch not being installed, but that hasn't been showing up again). There is a line about "No module named 'PIL'".

ComfyUI-Nvidia-Docker-2025-10-04T03-52-17.log