Linked "output" directory causes multiple issues

[TExtubation]

On my Linux system if "output" directory is a link the following error shows in terminal. The progress, status, preview, and statistics do not function properly either. A real directory does not show error or have any other issues.

[DEBUG] clip.hpp:401  - token ,
[DEBUG] clip.hpp:304  - token length: 154
Traceback (most recent call last):
  File "/home/nightstalker/LLM/sd.cpp-webui/venv/lib/python3.13/site-packages/gradio/queueing.py", line 667, in process_events
    response = await route_utils.call_process_api(
               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    ...<5 lines>...
    )
    ^
  File "/home/nightstalker/LLM/sd.cpp-webui/venv/lib/python3.13/site-packages/gradio/route_utils.py", line 349, in call_process_api
    output = await app.get_blocks().process_api(
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    ...<11 lines>...
    )
    ^
  File "/home/nightstalker/LLM/sd.cpp-webui/venv/lib/python3.13/site-packages/gradio/blocks.py", line 2284, in process_api
    data = await self.postprocess_data(block_fn, result["prediction"], state)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/nightstalker/LLM/sd.cpp-webui/venv/lib/python3.13/site-packages/gradio/blocks.py", line 2068, in postprocess_data
    await processing_utils.async_move_files_to_cache(
    ...<3 lines>...
    )
  File "/home/nightstalker/LLM/sd.cpp-webui/venv/lib/python3.13/site-packages/gradio/processing_utils.py", line 676, in async_move_files_to_cache
    return await client_utils.async_traverse(
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
        data, _move_to_cache, client_utils.is_file_obj_with_meta
        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    )
    ^
  File "/home/nightstalker/LLM/sd.cpp-webui/venv/lib/python3.13/site-packages/gradio_client/utils.py", line 1206, in async_traverse
    new_obj.append(await async_traverse(item, func, is_root))
                   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/nightstalker/LLM/sd.cpp-webui/venv/lib/python3.13/site-packages/gradio_client/utils.py", line 1201, in async_traverse
    new_obj[key] = await async_traverse(value, func, is_root)
                   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/nightstalker/LLM/sd.cpp-webui/venv/lib/python3.13/site-packages/gradio_client/utils.py", line 1197, in async_traverse
    return await func(json_obj)
           ^^^^^^^^^^^^^^^^^^^^
  File "/home/nightstalker/LLM/sd.cpp-webui/venv/lib/python3.13/site-packages/gradio/processing_utils.py", line 647, in _move_to_cache
    _check_allowed(payload.path, check_in_upload_folder)
    ~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/nightstalker/LLM/sd.cpp-webui/venv/lib/python3.13/site-packages/gradio/processing_utils.py", line 592, in _check_allowed
    raise InvalidPathError(msg)
gradio.exceptions.InvalidPathError: Cannot move /home/nightstalker/LLM/sd.cpp-webui/outputs/txt2img/20251218_114806_144115_preview.png to the gradio cache dir because it was not created by the application or it is not located in either the current working directory or your system's temp directory. To fix this error, please ensure your function returns files located in either the current working directory (/home/nightstalker/LLM/sd.cpp-webui), your system's temp directory (/tmp) or add /home/nightstalker/LLM/sd.cpp-webui/outputs/txt2img to the allowed_paths parameter of launch().

And thank you for this wonderful tool, it has been fun exploring its capabilities.

[daniandtheweb]

If the folder is a link I guess Gradio doesn't allow its usage for security reasons. I'll look deeper into this as I actually thought that was allowed.

[ali0une]

Hi there.

@TExtubation @daniandtheweb just modify

sd.cpp-webui/sdcpp_webui.py

Line 159 in 657c345

# Pass the arguments to sdcpp.launch with argument unpacking

like :

    # Pass the arguments to sdcpp.launch with argument unpacking
    sdcpp.launch(**launch_args,
    allowed_paths=["/tmp", "./outputs/"])

[daniandtheweb]

@ali0une Thanks for the suggestion, however I don't really like the solution of hard-coding directories. I'll work on some automatic way to detect which folders must be accessed from the config.json file.

Also I think it'll be better hiding this option behind a new flag like --insecure or something like this as this can potentially become a security vulnerability.

[daniandtheweb]

Can you check the latest release with the new --allow-insecure-dir and tell me if it works?

With this option you can set whatever directory you want in the settings and, after a restart of the program, that directory should be allowed without any problems.

[TExtubation]

I did a complete delete and rebuild of the webui along with a new build of sd.cpp for this test.
There are no more terminal errors when using --allow-insecure-dir , but the progress, status, preview, and statistics sometimes start, but they do not finish. After a couple steps they stop updating and just stay where they are. The terminal keeps showing updates and the final completion, but the webui does not update. I can see the preview image updating in the "output" directory itself. The finished image does show in the gallery, but a page refresh is required to start a new run.
The "stop" button does seem to function as the terminal shows a "Subprocess terminated." and the webui refreshes, as it should, to allow a new run.

[daniandtheweb]

Can you share an example of command that your generation uses? I'd like to try reproducing it on my end. Also send me the console log of what's happening, this could be an issue on how the program parses the logs.

[TExtubation]

I'm scratching my head now. I just tried it again, and to my amazement it worked. All the way through the image build, it worked the way it is supposed to. It didn't stop like it had been doing last night. But then I ran it again, only the steps changed from 24 to 30, hit generate, it said "initializing" and it hung there. Terminal shows the steps progressing, but the webui is not updating, and once the terminal saved the finished image to the directory the webui did not update to show the image or reset. It still shows initializing. There have still been no errors in the terminal, I use -v as well.

The following is the generation I've been testing with different models:

./sd-cli -M img_gen -p "<lora:lineart_style_illustriousXL:0.5>, line art, (black and white:2), Artgerm, rossdraws, fantasy art, a man with broad shoulders, large body build, in a dark grey Victorian suit. A small (white ram's head with dark colored horns:1.6) on a slim short white neck. Two long curled symmetrical dark colored horns. Hands have five fingers each and black fingernails. Is sitting in chair behind a large ornate wooden desk in dark manor room with books lining the walls. It is night outside." -n "(wide horns:2), armor, hair on head, jewelry, asian, man-goat, mask, human head, fluffy, hair down the back, long hair, paintings, electronics, white suit, wrist watch, large head, hair around neck, grey fur, neck tie, (embedding:lazyhand)," --sampling-method euler --steps 30 -W 1024 -H 1024 -b 1 --cfg-scale 4 -s -1 --clip-skip 2 --embd-dir /home/nightstalker/LLM/sd.cpp-webui/models/embeddings/ --lora-model-dir /home/nightstalker/LLM/sd.cpp-webui/models/loras/ -t 0 --rng cuda --sampler-rng cuda --lora-apply-mode at_runtime -o /home/nightstalker/LLM/sd.cpp-webui/outputs/txt2img/20251225_085027_044733.png --model /home/nightstalker/LLM/sd.cpp-webui/models/checkpoints/dreamshaperXL_lightningDPMSDE.safetensors --vae /home/nightstalker/LLM/sd.cpp-webui/models/vae/dreamshaperXL_lightningDPMSDE_vae.safetensors --scheduler karras --vae-tile-overlap 0.5 --vae-tile-size 32x32 --prediction eps --preview proj --preview-path /home/nightstalker/LLM/sd.cpp-webui/outputs/txt2img/20251225_085027_044733_preview.png --preview-interval 1 --vae-tiling --diffusion-fa --diffusion-conv-direct --vae-conv-direct --force-sdxl-vae-conv-scale --preview-noisy --color -v

This command has been working just fine up until the e9bbc6c commit, which is when my distro updated python to 3.14.2 (Void Linux rolling release) which caused the webui to no longer build properly (dies on building a wheel). I wound up using pyenv to get python 3.13.11 (which is what my system was using until it updated), which allows the webui to build and compile without issue.
My system is a AMD Ryzen 9 7940HS with 64gb of ram and a Radeon RX 7700S w/8gb vram.

[TExtubation]

Here is the log for the 2 runs I just did. The first acted like normal, the second stalled and never picked back up.

log.txt

github wouldn't let me paste it into the comment.

[daniandtheweb]

About the newer Python not working that's unfortunately expected. The Gradio version that the UI uses is a bit old (I think it's from September). Gradio introduced a strange graphical bug some time ago and I'm still thinking if it's better to just deal with it and enjoy the other improvements of the latest updates or keep using the old version until they fix it.

Thanks for the logs, I'll try to recreate the issue on my pc and fix it.

[daniandtheweb]

I've just released a new update, you can check it out and see if it seems more reliable.

I haven't been able to reproduce your issue no matter how much I tried. My only conclusion may be that Python wasn't able to keep up with the amount of logs present when using -v (however this is just a guess).

[TExtubation]

Unfortunately it still seems the webui gets stuck most of the time, but if I switch to the gallery then switch back it catches back up to where it is supposed to be. I even tried removing the linked "outputs" directory and using the normal created directories and it still seems to do it. I even unchecked verbose (-v) with no change.
I appreciate the time you've spent trying to fix this, but as it seems like no one else seems to be having this issue your time may be better spent elsewhere.
As a side note, what version of python are you using specifically?

[daniandtheweb]

I'm currently using Python 3.13 in my virtual environment.

You can open a new issue explaining this problem, if anyone else has a similar issue it could be easier to implement a fix for it.

[ali0une]

FYI Works for me 100%. Many thanks.