martial

Can you explain what you mean? I do not control the updates of the Comfy core, each user has to manually update ComfyUI from the manager to update it. My local instance is running: ComfyUI: v0.6.0-10-g36deef2c (2025-12-26) Manager: V4.0.4

If anyone is using Traefik in front of the tool, I added a new "solved" issue about: If you are using Traefik in front of ComfyUI or a few other services, see and use https://www.reddit.com/r/selfhosted/comments/1ph9jio/traefik_v364_breaks_nextcloud_officecollabora/ I was unable to load or save workflows until I added the allowEncodedSlash (workflow/file.json)

I think your problem is that the node itself depends on a 3rd party tool that needs to be compiled to work, per git+https://github.com/SarahWeiii/diso.git and for unclear reason it does not see torch which is installed by default That is what the userscripts_dir try to do for a few common packages. The closest entry in there that would do the build in the SageAttention script which also does the python3 setup.py install step, but I am not sure if even with that you would encounter the same error again.

The init script logic attempts to install uv if you have USE_UV=true Set it to USE_UV=false that should skip that part. Given the nature of Comfy and its constant evolution, I have never considered the container as an "offline" solution.

Hi Team, A quick update: I just released a new version of the tool Today (20251129). I recommend you enable the USE_UV option (set to true) to really speed up package installation. I also just released a new Community Application to use with ComfyUI Nvidia Docker. When reviewing images, I like to see the workflows prompts to try to understand how I can improve my generations. A month ago, Biagio announced a cool tool called "SmartGallery for ComfyUI" on Reddit https://www.reddit.com/r/comfyui/comments/1ogrfwb/smartgallery_v130_your_comfyui_gallery_just_got/ I used it and starting integrating new features to it in PRs that Biagio has since merged. I released a Docker container for it Today and as you can expect I added an Unraid template to use it too ;)

a 405 is a "method not allowed" error, which is very weird to see. I expect your Comfy installation is not too old, there seems to have been a similar error posted on their GH but that was March this year and the issue appears to be related to the reverse proxy is use in front of Comfy GitHub[Bug]: Save workflow 405(Method Not Allowed) When using N...Frontend Version COMFYUI: v0.3.4 Expected Behavior When using a reverse proxy e.g. nginx, Save workflow should work, in previous version this issue was not there. Actual Behavior Here is the api th...

Sadly, I do not have a magic solution for this, unless you are able to force its installation from the "Manager" while using Comfy. My usual solution for those types of issues is to reinstall ComfyUI and the virtual environment needed to run my custom nodes (ie, a couple of re-runs with re-downloads --and using the Manager to reinstall failed nodes, which will have failed because the venv does not contain the expected content) To do this, I recommend deleting (or renaming) the run folder in /mnt/user/appdata/comfyui-nvidia/mnt so that a new one can be created. Comfy will redownload, and after the "couple of failed nodes reinstall from the manager" step, you should be back in business.

That is likely a Samba share issue, you have created a user on Unraid for that share but the files in basedir are owned by "99:100". Keep in mind that files in the run folder need to stay owned by 99:100 (the default user running apps usually) For basedir it should be fine to have alternate ownership, as long as the user can read the files. The FORCE_CHOWN is here to try to fix that when you restart the container (and was added specifically for Unraid in that case) Enjoy. I am not sure how much longer we will be able to support GTX series hardware, and I do not have one to test anymore.

I think this is a problem in the README.md, I apologize. In the code, if you set DISABLE_UPGRADES I skip the PREINSTALL_TORCH step. So the README.md should have read enable DISABLE_UPGRADES after initial installation. Can you try again please with DISABLE_UPGRADES set to false for the initial installation? (please delete the appdata installation path for a clean install)

Just wanted to say thank you. I am leaving browsers on multiple systems open on the various pages of the dashboard and not a single occurrence!

I just did, I saw 7.1.1 released followed up by 7.1.2 so I was unclear if I should wait, but that error convinced me. Will report if I see it again. Thank you

I am still on 7.0 as I am waiting a few days to update to 7.1 It has happened to me twice in the past 24 hours (likely an open tab that I need to find), so I have updated my manual process with a script; the echo lines tell you what it does #!/usr/bin/env bash echo "Cleaning up /var/log/syslog" > /var/log/syslog &\ > /var/log/syslog.1 &\ > /var/log/syslog.2 echo "Cleaning up /var/log/nginx/error.log" > /var/log/nginx/error.log & > /var/log/nginx/error.log.1 echo "Find the master process and kill it" ps -axfo pid,ppid,uname,cmd | grep nginx | grep -v '\\_' | awk '{print $1}' | xargs kill -9 echo "Wait 10 seconds" sleep 10 while true; do echo "Attempting to start nginx" /etc/rc.d/rc.nginx start sleep 10 echo "Check nginx status" /etc/rc.d/rc.nginx status | grep "is running" && echo "nginx is running"; exit 0 done I also added it to my GH https://raw.githubusercontent.com/mmartial/unraid-study/refs/heads/main/varlog_nginx.sh

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.

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/*

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

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

Hi Team, I was made aware the container was not listed in CA anymore. Fixed: syntax error in XML

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.

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.

@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.

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

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?

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

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

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" ?