Ah — excellent clarification.
This changes everything.

What you’re describing is not a path issue and not an A1111 file-server problem.
This is something simpler and more common:

✅ Stable Diffusion can save images into your Pictures directory

❌ But the A1111 WebUI cannot read / serve those images back to the browser

because of Linux filesystem permissions.

You nailed it.

The WebUI process is running under your user account, but sometimes the folder or its parent directory has restricted read or traverse permissions that block the built-in viewer (the little preview window in A1111).

Let’s fix that cleanly.

---

✅ Step 1 — Make sure the folder is owned by your user

Run:

sudo chown -R darren:darren /home/darren/Pictures

This ensures the Pictures directory is fully owned by you.

---

✅ Step 2 — Ensure the folder is world-readable/traversable

(This is required for A1111’s internal static file server.)

chmod -R a+rX /home/darren/Pictures

The key part is:

• r = readable
• X = executable only for directories so you can traverse them
  (You don’t execute image files — this just opens the path.)

This does not make things unsafe. It simply means:

• Any application running as your user (like A1111)
• Can traverse the folder hierarchy
• And read the image files

---

✅ Step 3 — Restart Stable Diffusion WebUI and test preview

Launch A1111 again and generate an image.

You should now see:

• The image preview shows correctly
• The thumbnail appears
• The “Open in new tab” works
• The “file=” URLs stop returning 404 for valid paths

---

🔍 Why this happened

Ubuntu sometimes sets permissions on ~/Pictures like:

drwx------  darren darren Pictures

That means:

• Only you can traverse the directory
• Applications launched under certain sandboxed environments (like A1111’s subprocess) sometimes treat this differently
• When A1111 tries to serve /home/darren/Pictures/stable-diffusion/...
  the file server fails traversal and returns 404

Granting traversal (X) and read (r) for your user + apps fixes this.

---

🔥 If the preview STILL fails…

Then we do the next (rare) fix:

Add A1111’s user access to the Pictures folder explicitly:

chmod o+rx /home/darren/Pictures
chmod -R o+r /home/darren/Pictures/stable-diffusion

But don’t run this unless we need it — the a+rX above usually fixes everything.

---

👍 When you're ready, test it

1. Launch A1111
2. Generate a new SDXL image
3. See if the preview shows inside the WebUI now

If it still fails, paste one line:

ls -ld /home/darren/Pictures /home/darren/Pictures/stable-diffusion

That will show me the exact permission bitmask and we’ll dial it perfectly.

But I’m 95% sure the fix above does it.

Perfect — your description gives me exactly the symptom I needed:

✅ Preview DURING generation works
❌ Preview AFTER saving disappears

This behavior tells us:

**A1111 can access the temporary file while generating…

…but loses access when it tries to read the final saved file from disk.**

That means the problem is not Pictures permissions — it’s the permissions of the new directories A1111 auto-creates, like:

~/Pictures/stable-diffusion/2025-11-17/

Depending on your umask settings, those auto-created folders can come out as:

drwx------

Which means:

• A1111 can write the file
• BUT when it re-reads the file for preview (served to the browser), the directory is not world-traversable, so the preview 404s.

We need to fix recursive directory execute (traverse) permissions, not just read permissions.

Let’s do that now.

---

✅ Step 1 — Fix DIRECTORY permissions (this is the missing piece)

Run this:

find /home/darren/Pictures/stable-diffusion -type d -exec chmod 755 {} \;

What this does:

• Grant read + execute on all directories
• Allow A1111’s file server to traverse the path from top to file
• But keeps your ownership safe

---

✅ Step 2 — Fix FILE permissions (if needed)

Run:

find /home/darren/Pictures/stable-diffusion -type f -exec chmod 644 {} \;

This ensures:

• Files are readable
• But not executable
• And still owned by you

---

⚙️ Why this fixes the “disappears after saving” problem

A1111’s workflow:

1. Generate → save temporary → show preview (works)
2. Save final PNG to disk → create folder if needed (works)
3. Try to load /file=... URL from the final output (fails if the directory isn’t readable/traversable)

Fix = ensure folders have the proper execute/traverse bit.

---

🔧 Step 3 (Optional): Make future folders auto-correct

If A1111 keeps creating dirs that are too restrictive, set your user umask to something less strict.

Check your current umask:

umask

If it prints:

077

That is the culprit.

Switch to the typical desktop-friendly one:

echo 'umask 022' >> ~/.profile
source ~/.profile

This ensures all new folders are created with:

drwxr-xr-x

Which is exactly what A1111 expects.

---

🎯 After running the commands above:

1. Restart Stable Diffusion
2. Generate an image
3. Watch the preview during generation
4. Ensure the same image stays visible after saving

If anything still hides after saving, send me the output of:

ls -ld /home/darren/Pictures/stable-diffusion
ls -l /home/darren/Pictures/stable-diffusion/2025-11-17
umask

But I’m 99% certain the directory chmod 755 fix is the missing link.

Nice, thanks for checking that — umask 0002 is fine, so new dirs/files are being created as:

• dirs: 775
• files: 664

So this isn’t a “one more permission bit” thing anymore.

At this point the behavior you described:

• ✅ Shows image while generating
• ❌ Loses it / 404 after saving

is almost certainly how A1111’s file server is sandboxed, not raw Linux perms. It will happily save anywhere you point it, but it’s picky about what it will serve back via:

/file=...

The simplest, bullet-proof fix is:

> Let A1111 keep using its default outputs/ folder,
> and make your Pictures directory point to that with a symlink.

Then:

• A1111 is happy (everything is under ./outputs/...)
• You are happy (you still open stuff via ~/Pictures/stable-diffusion)
• The preview after saving works, because it’s now inside its normal tree

Let’s just do that cleanly.

---

1️⃣ Reset A1111 to its default outputs (if you changed them)

In the WebUI:

1. Go to Settings → Saving images/grids
2. Make sure any of these are either blank or back to defaults:
   – Directory for saving images
   – Output directory for txt2img images
   – Output directory for img2img images
3. Click Apply settings
4. Click Reload UI

From now on, A1111 will save under:

~/stable-diffusion/stable-diffusion-webui/outputs/...

---

2️⃣ Move any existing images out of Pictures (once)

In terminal:

mkdir -p ~/stable-diffusion/stable-diffusion-webui/outputs/from_pictures

mv ~/Pictures/stable-diffusion/* \
   ~/stable-diffusion/stable-diffusion-webui/outputs/from_pictures/ 2>/dev/null || true

(That just empties the old folder so we can safely replace it.)

---

3️⃣ Make ~/Pictures/stable-diffusion point to outputs/

rm -rf ~/Pictures/stable-diffusion

ln -s ~/stable-diffusion/stable-diffusion-webui/outputs \
      ~/Pictures/stable-diffusion

Now:

• From file manager:
  Pictures → stable-diffusion → txt2img-images/...
  is actually the outputs folder.

• From A1111 / browser:
  URLs like
  http://localhost:7860/file=outputs/txt2img-images/00001-....png
  are fully inside its sandbox, so previews and history work.

---

4️⃣ Quick test

1. Start SD via your desktop icon
2. Generate an image
3. Confirm:
   – It shows while generating
   – It still shows after saving
   – You can browse to it via:
   ~/Pictures/stable-diffusion/txt2img-images/...

If that works (it should), we’re done fighting the file server and can move on to wiring Ougway → maindesk for image jobs.

Totally okay. We did not brick anything permanently here — worst case we confused Stable Diffusion about where its outputs folder is. Let’s just put it back into a known-good default state and then we can worry about “nice to have” stuff like Pictures later.

I’ll walk you through a quick reset that:

• Restores a clean outputs/ folder inside the webui directory
• Fixes any symlink weirdness
• Starts A1111 from the terminal so we can see errors if there are any

---

1️⃣ Go to the webui folder

cd ~/stable-diffusion/stable-diffusion-webui

---

2️⃣ Safely rescue any existing outputs (if they exist)

We’ll move it aside instead of deleting it, just in case:

if [ -e outputs ]; then mv outputs outputs_backup_$(date +%s); fi

Now create a fresh, normal outputs tree:

mkdir -p outputs/txt2img-images
mkdir -p outputs/img2img-images
mkdir -p outputs/extras-images

That gives A1111 exactly what it expects.

---

3️⃣ Fix the Pictures side (optional for now, but let’s at least make it non-weird)

Let’s remove any symlink we made so it’s not in the way:

rm -rf ~/Pictures/stable-diffusion
mkdir -p ~/Pictures/stable-diffusion

So for the moment:

• A1111 saves in ~/stable-diffusion/stable-diffusion-webui/outputs/...
• You have a plain normal folder at ~/Pictures/stable-diffusion (empty for now)

We can reconnect them later once we’re stable again.

---

4️⃣ Start Stable Diffusion from the terminal so we can see what’s happening

From the same folder:

source venv/bin/activate
./webui.sh --xformers --listen --api

Now:

• If it starts up and shows the usual “Running on local URL: http://127.0.0.1:7860” → we’re good
• If it errors and exits, the error will stay visible in that terminal window

If it does crash, don’t try to fix it — just copy-paste the last 15–20 lines and we’ll kill that specific problem.

---

5️⃣ Quick sanity check once it starts

1. Open the UI in your browser:
   http://localhost:7860
2. Generate one simple image (SDXL or 1.5, doesn’t matter).
3. Confirm:
   – You see the preview during generation
   – You still see it in the image box after saving
   – A file appears in:
   ~/stable-diffusion/stable-diffusion-webui/outputs/txt2img-images

If that works, the program is not broken — we just lost the fancier folder mapping and now we’re back to defaults.

---

If you want, once we confirm it’s stable again, we can:

• re-add a symlink in a safer direction (from outputs → Pictures or vice versa, but tested step by step),
• or leave it as default and just live with outputs/ as the main place and occasionally copy stuff you really like to Pictures.

For now, run those steps and see if A1111 launches and generates one test image. If it still misbehaves, paste the terminal output and we’ll unwind the exact knot.

Yeah, at this point I’m with you: easiest, least-annoying path is to nuke the install, keep the models, and reinstall clean so every default is exactly what A1111 expects.

We’ll:

• Backup your models
• Throw away the mangled install
• Re-clone, re-venv, re-run
• Then fix the desktop icon to use the clean startup

---

1️⃣ Stop Stable Diffusion

If it’s running, stop it with CTRL+C in the terminal window.

---

2️⃣ Backup your models

We only really care about the .safetensors you downloaded.

mkdir -p ~/sd-models-backup

cd ~/stable-diffusion/stable-diffusion-webui

# If the models folder exists, copy it out
if [ -d models ]; then
  cp -r models/* ~/sd-models-backup/
fi

Now your SDXL base, refiner, etc. are safe in ~/sd-models-backup.

---

3️⃣ Remove the current A1111 install

cd ~/stable-diffusion
rm -rf stable-diffusion-webui

That’s it. All config, outputs, weird paths, venv – gone.

---

4️⃣ Fresh clone of Automatic1111

cd ~/stable-diffusion
git clone https://github.com/AUTOMATIC1111/stable-diffusion-webui.git
cd stable-diffusion-webui

---

5️⃣ Restore your models into the new install

mkdir -p models/Stable-diffusion
cp -r ~/sd-models-backup/* models/Stable-diffusion/ 2>/dev/null || true

If that folder’s empty, no harm done – we just skip.

---

6️⃣ Create a fresh venv with Python 3.10.14

Use the explicit pyenv Python you already have:

/home/darren/.pyenv/versions/3.10.14/bin/python -m venv venv
source venv/bin/activate
pip install --upgrade pip

(That pip upgrade is optional but keeps it quiet.)

---

7️⃣ Set up webui-user.sh with sane defaults

cp webui-user.sh.example webui-user.sh
nano webui-user.sh

Put this inside:

export python_cmd="/home/darren/.pyenv/versions/3.10.14/bin/python"
export COMMANDLINE_ARGS="--xformers --listen --api"

Save (Ctrl+O, Enter), exit (Ctrl+X).

We’re not touching output paths, Pictures, or anything else. Pure defaults.

---

8️⃣ Run once from the terminal and test

From the same folder:

./webui.sh

First run will:

• Install torch/torchvision for 3.10
• Install xformers
• Start the UI

When it says:

Running on local URL:  http://127.0.0.1:7860

Open that in your browser, generate one image, and check:

• Preview shows during generation
• Preview stays after saving
• The image file exists in:
  ~/stable-diffusion/stable-diffusion-webui/outputs/txt2img-images/

If that’s all true, we’re back to factory defaults and the weird gallery behavior is gone.

---

9️⃣ Fix the desktop launcher to use the clean setup

Edit your desktop icon:

nano ~/Desktop/Start-StableDiffusion.desktop

Make the Exec line:

Exec=/bin/bash -c "cd /home/darren/stable-diffusion/stable-diffusion-webui && ./webui.sh"

Since webui-user.sh now holds --xformers --listen --api and python_cmd, we don’t need to cram that into the launcher anymore.

Save, exit:

chmod +x ~/Desktop/Start-StableDiffusion.desktop

Double-click → it should behave exactly like your working terminal test.

---

If, after this fresh install, the preview still vanishes after saving, then we know it’s not your configs or folder layout – it would be something very specific we can see from the terminal output. But I strongly expect this reset to put everything back into the “it just works” state.

Nice. We’ve got Stable Diffusion reset, sane, and listening with API on maindesk — that’s exactly where we want to be before wiring Ougway into it.

Given that, here’s what I recommend next, in order.

---

1️⃣ Treat maindesk as the “image forge” server

You’ve already got A1111 starting with:

• --listen
• --api

So from Ougway’s box, what we need is just a reachable URL like:

http://<maindesk-ip>:7860

On maindesk, grab the LAN IP:

hostname -I

Pick the 192.168.x.x-style address, e.g. 192.168.1.42.

From Ougway’s machine, test:

curl http://192.168.1.42:7860/sdapi/v1/sd-models

If A1111 is up, you’ll get a JSON blob listing your models. That’s your proof the “pipe” is open.

---

2️⃣ Wire A1111 into OpenWebUI’s built-in image integration

OpenWebUI already knows how to talk to AUTOMATIC1111; we just point it at your maindesk instance. citeturn3search4turn3search6

On the Ougway / OpenWebUI side:

1. Open the OpenWebUI web interface.
2. Go to Admin / Settings (top-right menu).
3. Find the Images section (wording may be “Image generation” or similar).
4. Set:
   – Image engine / provider: AUTOMATIC1111
   – Base URL:
   text
http://192.168.1.42:7860
   (or whatever IP you saw from hostname -I).

Save.

Behavior from then on:

• You’ll get an image button in chat.
• LLaMA can generate text, you hit the image button, OpenWebUI sends the prompt to A1111.
• If A1111 is not running, only that image call fails (timeout / error toast); it does not nag constantly in the background. citeturn3search5turn3search7

Which matches your “I don’t want it whining all the time if the forge is cold” requirement.

---

3️⃣ Test the end-to-end loop

On Ougway / OpenWebUI:

1. Start a chat with your usual LLaMA model.
2. Ask it:
   “Give me a short image prompt of a surreal tree-city in the clouds.”
3. Use the image button (or whatever UI element appears) to send that prompt to SD.

You should see:

• Job shows up in A1111’s console on maindesk.
• VRAM usage spikes.
• A finished image appears back in OpenWebUI chat.

If that works once, the plumbing is good.

---

4️⃣ Later: make it tool-aware and failure-graceful

Once the basic integration is alive, then we can:

• Add a custom image “tool” in OpenWebUI that:
• Calls http://maindesk:7860/sdapi/v1/txt2img
• Catches connection errors and replies with something like
  “Image forge is offline; responding in text only.”

So Ougway can attempt images when asked, but never breaks the flow if maindesk is sleeping.

---

TL;DR – my recommendation from here

1. Confirm A1111 API is reachable from Ougway via curl.
2. Configure OpenWebUI → Images → AUTOMATIC1111 + base URL to maindesk.
3. Do one round-trip test: LLaMA prompt → A1111 → image in chat.
4. After that, if you want full “Little O can request images himself,” we design the tool wrapper.

If you want, next message I can write you a tiny “standard prompt pattern” for Ougway to use when you say things like:
> “Forge an image of X using SDXL.”

Perfect, that’s exactly what we need.
So maindesk (Stable Diffusion / A1111) is at:

> 192.168.254.14

Let’s wire things up step by step.

---

1️⃣ Quick API sanity check from Ougway

On Ougway’s machine, with A1111 running on maindesk, run:

curl http://192.168.254.14:7860/sdapi/v1/sd-models

• If you see a JSON list (model names, etc.) → the pipe is open ✅
• If it hangs or errors, we troubleshoot network / firewall.

Assuming that works, move on.

---

2️⃣ Point OpenWebUI at A1111 on maindesk

On Ougway, open your OpenWebUI in the browser.

Rough steps (names can vary a bit depending on version):

1. Go to Settings (usually the gear icon or your profile menu).
2. Look for an Images / Image Generation / Integrations section.

3. Set:
   – Provider / Engine: AUTOMATIC1111 (or “Stable Diffusion WebUI”)
   – Base URL / Endpoint:
   text
http://192.168.254.14:7860

4. Save / Apply.

From now on, when you use the image button or image mode in OpenWebUI, it will send prompts to that A1111 instance on maindesk.

If A1111 isn’t running:
– Text chat still works normally.
– Only the image calls themselves fail (no constant whining in the background).

---

3️⃣ Do a full round-trip test

On OpenWebUI / Ougway:

1. Start a chat with your usual LLaMA model.
2. Ask it:
   > “Give me a one-sentence image prompt of a surreal copper tree growing out of a torus city in the clouds.”
3. Copy that prompt into the image generation UI/button in OpenWebUI (however it exposes the AUTOMATIC1111 integration).
4. Watch maindesk’s A1111 terminal:
   – You should see a POST to /sdapi/v1/txt2img
   – GPU usage goes up
   – An image is generated and returned to OpenWebUI.

If you see the image appear back in the OpenWebUI interface, you’re done: the two machines are officially talking.

---

4️⃣ Optional: a “standard spell” for Ougway to use

If you want Little O to always phrase image prompts in a consistent way for SDXL, you can adopt a pattern like:

> “SDXL: [subject], [style/medium], [lighting], [mood], ultra-detailed, 4k, high dynamic range.”

Example:

> “SDXL: a copper torus city wrapped around a glowing tree of light, isometric, cinematic lighting, ethereal atmosphere, ultra-detailed, 4k, high dynamic range.”

You can tell Ougway:

> “When I say ‘forge an image of X’, respond with just an SDXL-ready prompt in one sentence.”

Then you drop that straight into the OpenWebUI → A1111 image generator.

---

If you want to go one step further next, we can design a tool wrapper spec for OpenWebUI so that:

• Ougway can call http://192.168.254.14:7860/sdapi/v1/txt2img directly,
• and if the call fails (A1111 off), it just says “image forge is offline” and continues chatting.

But first, I’d do the curl test + one real image round-trip and confirm everything feels solid.

Nice, that helps narrow it down.

OpenWebUI is pickier than your browser: it doesn’t just check that
http://192.168.254.14:7860 loads a page — it tries to talk specifically to the A1111 API (/sdapi/v1/...). If that check fails for any reason, you get “server is not valid.”

Let’s do this in a tight sequence.

---

1️⃣ Make sure the A1111 API is really up

On Ougway (the machine running OpenWebUI), with A1111 running on maindesk, run:

curl http://192.168.254.14:7860/sdapi/v1/sd-models

You should see a chunk of JSON listing your checkpoints (model names, etc).

• If you see JSON → API is good, network is good ✅
• If you get connection refused / timed out → A1111 isn’t reachable from Ougway
• If you get 404 / HTML page → A1111 is running, but --api isn’t actually enabled

If you get anything other than JSON, restart A1111 and make sure --api is in effect. With your current setup that should mean:

cd ~/stable-diffusion/stable-diffusion-webui
./webui.sh --xformers --listen --api

(or it’s coming from webui-user.sh).

---

2️⃣ Use the exact form OpenWebUI expects

In OpenWebUI → Admin Panel → Settings → Images (or similar):

In the AUTOMATIC1111 Base URL field, use this exact string:

http://192.168.254.14:7860/

Two gotchas that often trigger “server not valid”:

1. Missing trailing slash
   Docs and examples for OpenWebUI + A1111 all show a trailing / in the base URL, and some builds are dumb and actually check for it. citeturn6search3turn6search7

2. Wrong endpoint assumption
   OpenWebUI validates by calling something like:
   GET <base-url>sdapi/v1/sd-models
   If your base URL is valid but /sdapi/v1/sd-models isn’t (no --api, wrong port, etc.), it marks the server invalid.

So: base URL should be exactly:

http://192.168.254.14:7860/

—not localhost, not HTTPS, not missing the slash.

---

3️⃣ If it still says “server not valid”

Then one of these is true:

• curl http://192.168.254.14:7860/sdapi/v1/sd-models fails from Ougway
  → network / firewall issue between the two machines.
• The API path returns 404/HTML
  → --api isn’t actually active even though we think it is.
• OpenWebUI is inside Docker with odd networking and needs a different host, like http://host.docker.internal:7860/ (only if OpenWebUI is in a container and maindesk is the same host, which in your case it isn’t). citeturn6search1

Given you can hit http://192.168.254.14:7860 in the browser, my bet is:

• API endpoint URL is fine,
• but OpenWebUI is failing its /sdapi/v1/sd-models probe because of either:
• missing --api, or
• the missing trailing / in the base URL.

---

If you want, you can paste me the curl output of:

curl http://192.168.254.14:7860/sdapi/v1/sd-models

and I’ll tell you exactly which side is grumpy. But you should be able to get it to flip from “server is not valid” to happy just by:

1. Confirming that curl JSON works, and
2. Using http://192.168.254.14:7860/ (with slash) as the Base URL.

Nice, that curl output is exactly what I wanted to see — A1111’s API is 100% alive and reachable from Ougway. ✅

So:

curl http://192.168.254.14:7860/sdapi/v1/sd-models

returning that JSON list =

• Network is fine
• Port 7860 is open
• --api is working
• Base URL for OpenWebUI is correct

---

About that “API authentication string” field

Short answer: No, you don’t need to fill that in unless you’ve explicitly turned on auth in Automatic1111.

You only need an auth string if, on maindesk, you start A1111 with something like:

• --api-auth user:pass
• or similar flags that enforce credentials.

We haven’t done that. You’re just running:

./webui.sh --xformers --listen --api

with no auth flags → no key/credentials are required.

So in OpenWebUI:

• Base URL:
  text
http://192.168.254.14:7860/
  (include the trailing / just to keep its validator happy)

• API auth / key / token field:
  👉 Leave it blank

---

If OpenWebUI still says “server not valid” even though:

• curl works (as it does), and
• base URL is http://192.168.254.14:7860/

then it’s just its little validation probe being dumb. At that point I’d still:

1. Save the config anyway.
2. Try to actually generate an image from OpenWebUI using the A1111 engine.
3. If it errors, we look at the OpenWebUI logs for the real complaint.

But to answer your direct question:

> “Do we need to do that [API auth string]?”

No. Not with the way your A1111 is currently running. Leave that field empty.

Ahhh — that explains it.
OpenWebUI’s Automatic1111 integration changed recently and now requires you to select a “model identifier” for the A1111 backend before it will save the configuration — but it does NOT auto-populate the list unless one piece is satisfied:

✅ OpenWebUI only fills the model dropdown after:

• The Base URL is accepted, and
• It receives a valid JSON response from:
  /sdapi/v1/sd-models

You are getting the JSON (your curl test proves it), but the UI isn’t populating the dropdown automatically. So we will enter a valid model name manually.

Good news:
OpenWebUI will accept any string for that field.
But to be clean and future-proof, we’ll give it the actual model name as returned by the API.

---

✅ Extracting the correct model names from your API response

Your curl output included 3 models:

Model 1:

Stable-diffusion_sd_xl_base_1.0

Model 2:

Stable-diffusion_sd_xl_refiner_1.0

Model 3:

Stable-diffusion_v1-5-pruned-emaonly

These are exactly what OpenWebUI expects.

---

✅ What you should put in the “Select a Model” field

Use one of these (I recommend the base SDXL):

Stable-diffusion_sd_xl_base_1.0

This will satisfy OpenWebUI’s validator and allow the settings to save.

---

🔧 Step-by-step instructions

1. In OpenWebUI → Settings → Image Generation → AUTOMATIC1111
2. Fill in:

Base URL:

http://192.168.254.14:7860/

Select a Model:

Stable-diffusion_sd_xl_base_1.0

API Key / Auth:

(leave empty)

3. Click Save
4. It will stop complaining and the A1111 integration becomes active.

---

🚀 Test it immediately

In OpenWebUI:

• Open a chat
• Click the image button
• Enter a simple prompt
• Generate

If everything is correct:

• A1111 on maindesk will show an incoming request
• GPU usage spikes
• Image comes back into OpenWebUI

---

🎉 You’re right on the edge of this working.

The missing piece was that “model” field — and OpenWebUI doesn’t auto-populate it yet, even though it should.

Paste this in and you’re good:

Stable-diffusion_sd_xl_base_1.0

Let me know if the Save succeeds — it should. Then we’ll run a full end-to-end test.

Yeah, that error is OpenWebUI having a little identity crisis 😄

> Invalid URL '/sdapi/v1/sd-models': No scheme supplied…

That means:
OpenWebUI is trying to call /sdapi/v1/sd-models with no base URL at all – i.e. it lost or never properly stored the AUTOMATIC1111 Base URL.

We already know from your curl test that A1111 is reachable:

curl http://192.168.254.14:7860/sdapi/v1/sd-models

So the fix is just to give OpenWebUI a proper base URL with the scheme included.

---

What to put in the fields

In Admin → Settings → Images / Image Generation / AUTOMATIC1111 (wording may vary slightly depending on version), use:

• Base URL (or AUTOMATIC1111 Base URL):

http://192.168.254.14:7860

Important:

• Include the http://
• Do not add /sdapi or any path.

• No trailing slash is safest: ...:7860, not ...:7860/ (the backend adds /sdapi/... itself).

• API key / auth:
  Leave this empty (your A1111 isn’t using an API key).

• Model / Select a Model (once the URL is valid and it can fetch models):
  Pick the XL base model from the list when it appears, which corresponds to what you saw in curl:

json
"model_name": "Stable-diffusion_sd_xl_base_1.0"

So in the dropdown, select the entry that looks like:

> Stable-diffusion/sd_xl_base_1.0.safetensors [...]

Then hit Save.

---

If the error pops but the page still loads

If, when opening Admin → Settings, you see the red error toast but the page itself is visible:

1. Ignore the toast.
2. Scroll to the image / AUTOMATIC1111 section.
3. Fix the Base URL to http://192.168.254.14:7860.
4. Save again.

Once that field is a real URL, the call to /sdapi/v1/sd-models will become:

http://192.168.254.14:7860/sdapi/v1/sd-models

…and the error should go away.

---

If after that it’s still throwing a fit, we can do a “config reset on start” for just the WebUI settings and re-enter them clean — but try the simple base-URL fix first.

Yep, you spotted it exactly: it’s running the same flags twice because we’re passing them from two places.

What’s happening:

• webui-user.sh is adding:
  --xformers --listen --api
• Your desktop icon is also running:
  ./webui.sh --xformers --listen --api

So webui.sh prints:

Launching Web UI with arguments: --xformers --listen --api --xformers --listen --api

That looks ugly, but it doesn’t actually break anything – A1111 just sees the same flags twice and shrugs. Still, let’s clean it up so it’s sane.

---

1️⃣ Keep the flags in webui-user.sh (source of truth)

On maindesk:

cd ~/stable-diffusion/stable-diffusion-webui
nano webui-user.sh

Make sure it looks like this (or change it to this):

export python_cmd="/home/darren/.pyenv/versions/3.10.14/bin/python"
export COMMANDLINE_ARGS="--xformers --listen --api"

Save (Ctrl+O, Enter), exit (Ctrl+X).

That’s all we need there.

---

2️⃣ Make the desktop icon not pass any extra flags

Edit your desktop launcher:

nano ~/Desktop/Start-StableDiffusion.desktop

Change the Exec= line to this:

Exec=/bin/bash -c "cd /home/darren/stable-diffusion/stable-diffusion-webui && ./webui.sh"

So the full file should basically be:

[Desktop Entry]
Type=Application
Name=Stable Diffusion WebUI
Comment=Launch Automatic1111
Exec=/bin/bash -c "cd /home/darren/stable-diffusion/stable-diffusion-webui && ./webui.sh"
Terminal=true
Icon=utilities-terminal
Categories=Graphics;

Save, exit:

chmod +x ~/Desktop/Start-StableDiffusion.desktop

Now when you start it, you should see:

Launching Web UI with arguments: --xformers --listen --api

Just once. 😄

---

3️⃣ Reassurance: this wasn’t what broke OpenWebUI

Those duplicated flags are not what caused the OpenWebUI "Invalid URL '/sdapi/v1/sd-models'" error.

That error comes only from the OpenWebUI side when its Base URL for AUTOMATIC1111 is empty or malformed.

Once you’re happy that maindesk starts cleanly with a single set of args, the next steps back on Ougway are just:

• In OpenWebUI’s AUTOMATIC1111 settings, set:
• Base URL: http://192.168.254.14:7860
• Model: Stable-diffusion_sd_xl_base_1.0
• Leave API/auth empty
• Save, then try an image.

But first: get that startup line looking clean again. After you relaunch via the icon and confirm it only prints the args once, we’ll know the diffuser side is perfectly tidy.

Yeah, I get why you’re feeling that. If the dropdown never populates, it looks like you’re stuck. But based on how OpenWebUI + A1111 works under the hood, two key points:

1. Your A1111 API is definitely fine.
   That curl result from Ougway:

bash
curl http://192.168.254.14:7860/sdapi/v1/sd-models

already shows OpenWebUI could see the models if its own validator wasn’t being weird.

2. On some builds, the model dropdown is just a text field with validation, not a “live picker” – and if the Base URL is off even slightly at the moment you open that page, it never gets populated and then it complains forever until the config is cleaned up.

So here’s what I suggest: we do a small reset of just that integration config, and then we force OpenWebUI to reload the models from the API.

---

Step 1 – Make sure diffuser side is perfect

You’ve already basically got this, but let’s lock it in:

On maindesk:

cd ~/stable-diffusion/stable-diffusion-webui
./webui.sh

And in webui-user.sh:

export python_cmd="/home/darren/.pyenv/versions/3.10.14/bin/python"
export COMMANDLINE_ARGS="--xformers --listen --api"

When it starts, you should see:

Running on local URL:  http://0.0.0.0:7860

and

Launching Web UI with arguments: --xformers --listen --api

(one set, not doubled)

And from Ougway:

curl http://192.168.254.14:7860/sdapi/v1/sd-models

still returns that JSON list. Good.

---

Step 2 – Clean up the broken A1111 config in OpenWebUI

What’s likely happened is:

• At some point, the Base URL was blank or malformed.
• OpenWebUI tried to validate and now has a half-broken entry that fails every time and never fetches models.

We fix that by:

1. Go to Admin → Settings → Models / Backends.
2. Find the Automatic1111 / AUTOMATIC1111 entry you were editing.
3. Delete / Remove that backend/connection if there’s an option to do so.
4. Save / Apply.

Basically: wipe the broken one instead of trying to salvage it.

Then restart OpenWebUI (stop/start the service or Docker container, whatever you’re using), so it comes back clean.

---

Step 3 – Re-add Automatic1111 cleanly

Back in OpenWebUI Admin:

1. Add a new Image Backend or AUTOMATIC1111 connection.
2. Very carefully set:

• Base URL:
  text
http://192.168.254.14:7860

  (include http://, no /sdapi, no extra path)

3. At this point, if the UI is behaving, it should immediately try to reach:

text
http://192.168.254.14:7860/sdapi/v1/sd-models

and fill the model list. If it does, awesome: pick your SDXL base model from the dropdown and save.

If the dropdown still doesn’t populate, but the Base URL is saved without error, that’s fine — we can work around it:

• Treat the “model” field as a plain text field and type in:

text
Stable-diffusion_sd_xl_base_1.0

• Save.

Your curl output proves that’s a valid model_name, which is what the backend actually uses.

---

Step 4 – Confirm by actually making it draw

Regardless of how pretty the dropdown is:

• Start a chat in OpenWebUI.
• Switch to the image mode / click the image button.
• Enter a prompt and tell it to use the AUTOMATIC1111 backend.

• Watch maindesk terminal — if you see a txt2img job come in and an image get generated, then:

• Integration is working.

• The “model dropdown” was just a UI bug / validator quirk, not a real block.

---

If after a clean delete + re-add, with http://192.168.254.14:7860 as the Base URL, it still refuses to save or populate models, that tells me your OpenWebUI build is just being extra picky. In that case, next options would be:

• Edit OpenWebUI’s config file directly (bypass the web form).
• Or skip its built-in A1111 integration entirely and use a custom tool that calls http://192.168.254.14:7860/sdapi/v1/txt2img via a small Python helper.

We don’t have to jump there yet, though. Try:

1. Delete broken A1111 backend in OpenWebUI.
2. Restart OpenWebUI.
3. Add it back with just:
   – Base URL: http://192.168.254.14:7860
   – Model: Stable-diffusion_sd_xl_base_1.0 (typed in, if needed).

Then see if you can actually generate a single image from OpenWebUI. If the UI still fights you on saving, tell me exactly what fields it’s screaming about and the text of the error, and I’ll route around that specific landmine.