2 months of frustration | Friends of the Crustacean 🦞🤝 | Page 1

barren estuary Apr 18, 2026, 6:24 PM

#

intel i-9 9900KS
rtx 3060 12gb
64 gb ddr4
35tb storage
Linux 6.12.54-Unraid x86_64

i've been trying to get openclaw up and running properly for 2 months with no success. in the last week i've been able to get into the ui, and i can access multiple ollama models and get responses. I can't create agents or subagents. I can't setup skills or use tools. I also find that on a laptop, trying to work through the ui config screens is super difficult.

is there a channel or thread that walks through setting up specifically tools to allow openclaw to interact with unraid, other docker containers, or create agents?

just looking for some help before i give up

wind cedarBOT Apr 18, 2026, 6:24 PM

#

silk mountainBOT Apr 18, 2026, 6:24 PM

#

To help others find answers, you can mark your question as solved via Right click solution message -> Apps -> ✅ Mark Solution

wind cedarBOT Apr 18, 2026, 6:24 PM

#

broken hillBOT Apr 18, 2026, 6:27 PM

#

That sounds exhausting, and yeah, I would stop fighting the laptop UI for this. CLI is usually way easier for first bring-up.

Short answer: I don’t know a single Unraid-specific walkthrough thread I’d trust end-to-end yet. For real human “who has done this on Unraid/docker?” experience, also ask in #users-helping-users. For actual troubleshooting, this thread is a good place.

A few important bits from the docs:

FAQ: https://docs.openclaw.ai/help/faq
Local models: https://docs.openclaw.ai/gateway/local-models
Multi-agent: https://docs.openclaw.ai/concepts/multi-agent
Subagents: https://docs.openclaw.ai/tools/subagents
Tools overview: https://docs.openclaw.ai/tools
Skills: https://docs.openclaw.ai/tools/skills

My honest first guess from your symptoms:

Ollama is working for chat, but not for tool/agent workflows. That’s a very common split.
Tool policy / skill visibility may be restricting things (tools.profile, tools.allow, tools.deny, agent skill allowlists).

#

Version mismatch could still be part of it.

If you paste these read-only outputs, I can usually tell which layer is broken pretty fast:

openclaw --version
openclaw status --all
openclaw models status
openclaw config get tools
openclaw config get agents
openclaw config get skills

Redact tokens/secrets before posting.

Also, for Unraid / docker container interaction, the main thing is usually tools/exec, not skills. Skills are optional guidance. So I’d debug this in this order:

#

version / status
model/tool-calling reliability
tools config
agents/subagents
skills last

If you paste those outputs here, I’ll help you go line by line. Don’t give up yet, this really does sound diagnosable. 🦐

marble mango Apr 18, 2026, 6:43 PM

#

barren estuary intel i-9 9900KS rtx 3060 12gb 64 gb ddr4 35tb storage Linux 6.12.54-Unraid x86...

How would you rate your Linux skill level? Beginner - Intermediate - Pro? I am just asking as I am a fucking UNIX pro since 35 years (AIX, Solaris, Debian, etc) and the entry hurdle is a bit more challenging than other systems I dealt with. Imho, you can smoke the UI right now, you should work hardcore at the admin console or using the shell with config files.

broken hillBOT Apr 18, 2026, 6:43 PM

#

Yeah, I agree with this take.

For Unraid + Ollama + agents/tools, I’d treat the UI as a monitor for now, not the primary setup path. Your hardware is not the problem here, this is almost certainly config/model/tooling friction.

If you’re comfortable in a shell, I’d start with these read-only checks:

openclaw --version
openclaw status --all
openclaw models status
openclaw config get tools
openclaw config get agents
openclaw config get skills

If plain chat works but tools/subagents/skills do not, the usual culprits are:

#

local model/backend can chat but is bad at tool calling
tool policy is too restrictive (tools.profile, tools.allow, tools.deny)
agent skill visibility is restricted (agents.defaults.skills, agents.list[].skills)

Docs for the relevant pieces:

If aceblack10 posts those outputs, we can probably narrow it down pretty quickly.

barren estuary Apr 18, 2026, 6:45 PM

#

OpenClaw Status (2026.4.15)

OS: Linux 6.12.54-Unraid (x64) | Node: 24.14.0

Gateway: ws://127.0.0.1:18789 (Local/Active)

IP: 192.168.50.30 | Lat: 33ms

Agents: 1 active / 5 sessions

Status: Up to date (pnpm) | Tailscale: Off

Services: systemd not installed

broken hillBOT Apr 18, 2026, 6:45 PM

#

This is actually useful, thanks. A few good signs here:

2026.4.15 is recent enough
Node 24.14.0 is fine
Gateway is up
systemd not installed on Unraid is expected, so I would not chase that

So this probably is not “OpenClaw is dead,” it’s more likely one of these:

local model/backend can chat but not handle tools/session calls well
tool policy is restricting things
skills/agent config is too narrow

Next things I’d want to see:

#

openclaw models status
openclaw config get tools
openclaw config get agents
openclaw config get skills

Redact secrets/tokens before pasting.

What I’m specifically looking for:

tools.profile: "minimal"
restrictive tools.allow
tools.deny blocking exec / session tools
agents.defaults.skills or per-agent skills: []
models showing only local Ollama, which would make the model/backend the prime suspect

#

And yep, for Unraid I’d 100 percent do this in the shell/config, not in the UI.

barren estuary Apr 18, 2026, 6:46 PM

#

Telegram: ON (OK) | Agent: main (Active 8m ago) | Sessions: 5 | Bootstrap: PRESENT

#

Diagnosis (read-only)

Gateway connection details:
Gateway target: ws://127.0.0.1:18789
Source: local loopback
Config: /root/.openclaw/openclaw.json
Bind: loopback

✓ Config: /root/.openclaw/openclaw.json
✓ Secret diagnostics (0)
✓ Restart sentinel: none
! Port 18789
Port 18789 is already in use.

pid 1 root: openclaw-gateway (*:18789)
Gateway already running locally. Stop it (openclaw gateway stop) or use a different port.
! Tailscale: off · unknown
✓ Skills: 6 eligible · 0 missing · /array/appdata/openclaw/workspace/.openclaw
✓ Plugin compatibility (none)
✓ Channel issues (none)

broken hillBOT Apr 18, 2026, 6:47 PM

#

Ah, Bootstrap: PRESENT is the first thing here that really jumps out.

Per the docs, BOOTSTRAP.md is a one-time first-run file and should be removed when bootstrap finishes: https://docs.openclaw.ai/start/bootstrapping

So if it’s still present, there’s a decent chance your main workspace still thinks bootstrap is pending, which can leave things in a weird half-configured state.

I would not delete anything blindly yet. First, can you paste these read-only checks:

openclaw config get agents
openclaw models status
openclaw config get tools
ls -la ~/.openclaw/workspace

And if your workspace path is different from ~/.openclaw/workspace, use the one shown by openclaw config get agents.

#

If you’re comfortable sharing it, also paste the first bit of:

sed -n '1,80p' ~/.openclaw/workspace/BOOTSTRAP.md

Right now my strongest leads are:

bootstrap never fully completed
local model/tool-calling issue
tool policy too restrictive

That Bootstrap: PRESENT line makes me think we may have finally found a real clue.

#

Okay, this is progress.

A few reads from that output:

Port 18789 is already in use is not the problem here, it just means your gateway is already running.
Skills: 6 eligible · 0 missing is actually good news. Skill discovery is working, so this is probably not “skills failed to install/load.”
That pushes me back toward tool policy / model tool-calling / workspace bootstrap.

Next I’d want these:

openclaw config get agents
openclaw config get tools
openclaw models status
ls -la /array/appdata/openclaw/workspace

#

If openclaw config get agents shows a different workspace path, use that one instead of /array/appdata/openclaw/workspace.

What I’m looking for now:

does that workspace still contain BOOTSTRAP.md
is tools.profile set too narrowly
are tools.allow / tools.deny blocking runtime/session tools
does models status show only local Ollama, which would make the model/backend the main suspect

Optional but useful too:

openclaw skills list

That’ll tell us whether the runtime sees the skills the same way the diagnosis does.

barren estuary Apr 18, 2026, 6:52 PM

#

{
"primary": "ollama/llama3.2:latest",
"workspace": "/array/appdata/openclaw/workspace/.openclaw",
"skipBootstrap": false,
"concurrency": { "main": 4, "subagents": 8 },
"models": ["mistral", "qwen2.5-coder:7b/1.5b", "llama3:8b", "gemma4-e4b", "gemma4:31b-cloud", "kimi-k2.5", "qwen3.5:397b", "sonnet"]
}

broken hillBOT Apr 18, 2026, 6:53 PM

#

Yep, I think we finally have a real smoking gun.

Your primary model is ollama/llama3.2:latest.

That would fit your symptoms really well:

plain chat works
tools feel broken
subagents feel broken
skills “exist” but don’t help much in practice

OpenClaw can talk through small local models, but full agent/tool workflows are much harsher. The local-model docs are pretty blunt about this: https://docs.openclaw.ai/gateway/local-models

A couple more useful reads from this:

subagents: 8 means subagents are not disabled by concurrency
your actual workspace looks like /array/appdata/openclaw/workspace/.openclaw

#

skipBootstrap: false means bootstrap is still in play, so if BOOTSTRAP.md is hanging around there, that can also make things weird

So my current ranking is:

primary model is too weak/unreliable for tool calling
tool policy may also be restricting things
possible lingering bootstrap file in the workspace

Can you paste just these last two read-only checks:

openclaw config get tools
ls -la /array/appdata/openclaw/workspace/.openclaw

If that directory listing shows BOOTSTRAP.md, I’d pay attention to that too.

#

But honestly, the ollama/llama3.2:latest primary already explains a lot. If you have a hosted model configured under that models list, I’d use that as the primary for debugging before blaming the rest of the stack.

barren estuary Apr 18, 2026, 6:56 PM

#

openclaw config get tools
ls -la /array/appdata/openclaw/workspace/.openclaw

🦞 OpenClaw 2026.4.15 (unknown) — I read logs so you can keep pretending you don't have to.

{
"profile": "coding",
"web": {
"search": {
"enabled": true,
"provider": "gemini",
"openaiCodex": {}
},
"fetch": {
"enabled": true
}
}
}
total 44
drwxr-xr-x 1 root root 226 Apr 17 23:22 .
drwxr-xr-x 1 root root 18 Apr 17 20:52 ..
drwxr-xr-x 1 root root 98 Apr 17 21:01 .git
drwxr-xr-x 1 root root 40 Apr 17 21:01 .openclaw
-rw-r--r-- 1 root root 7788 Apr 17 21:01 AGENTS.md
-rw-r--r-- 1 root root 5641 Apr 17 23:22 Agent_Creation_Guide.md
-rw-r--r-- 1 root root 1471 Apr 17 21:01 BOOTSTRAP.md
-rw-r--r-- 1 root root 193 Apr 17 21:01 HEARTBEAT.md
-rw-r--r-- 1 root root 636 Apr 17 21:01 IDENTITY.md
-rw-r--r-- 1 root root 1747 Apr 17 21:01 SOUL.md
-rw-r--r-- 1 root root 860 Apr 17 21:01 TOOLS.md
-rw-r--r-- 1 root root 477 Apr 17 21:01 USER.md
drwxr-xr-x 1 root root 144 Apr 18 01:01 memory
drwxr-xr-x 1 root root 0 Apr 17 20:52 state

broken hillBOT Apr 18, 2026, 6:57 PM

#

Okay, now we’re out of guesswork.

You have two real blockers:

tools.profile: "coding" means tools are not disabled
- so this is not a tools-allowlist problem
BOOTSTRAP.md is still sitting in the active workspace
- docs say that file is one-time and should go away after bootstrap finishes: https://docs.openclaw.ai/start/bootstrapping
your primary is still ollama/llama3.2:latest
- that is very likely too weak/unreliable for full tool + subagent workflows
- plain chat working does not prove tool-calling will work

So my honest read is:

skills are loading

#

tools are allowed
the workspace still looks half-bootstrapped
the primary model is a bad choice for debugging OpenClaw agent features

What I’d do next, in order:

Treat BOOTSTRAP.md as suspicious
- if you already have AGENTS.md, SOUL.md, IDENTITY.md, USER.md set up, I would move/rename BOOTSTRAP.md out of the way instead of deleting it
Use a stronger hosted model as primary for testing
- if that sonnet entry is actually configured/authenticated, that’s the one I’d test before blaming the rest of the stack
Then restart and retest

If you want the safest next step before touching anything, paste:

openclaw models status

#

If that shows the hosted model is really available, I think we’ve got a pretty clean path forward here.

barren estuary Apr 18, 2026, 6:58 PM

#

Config : ~/.openclaw/openclaw.json
Agent dir : ~/.openclaw/agents/main/agent
Default : ollama/llama3.2:latest
Fallbacks (2) : ollama/mistral:latest, ollama/qwen2.5-coder:7b
Image model : -
Image fallbacks (0): -
Aliases (1) : sonnet -> anthropic/claude-sonnet-4-6
Configured models (10): ollama/mistral:latest, ollama/qwen2.5-coder:7b, ollama/qwen2.5-coder:1.5b, ollama/llama3:8b, ollama/llama3.2:latest, ollama/bjoernb/gemma4-e4b-think:latest, ollama/gemma4:31b-cloud, ollama/kimi-k2.5:cloud, ollama/qwen3.5:397b-cloud, anthropic/claude-sonnet-4-6

Auth overview
Auth store : ~/.openclaw/agents/main/agent/auth-profiles.json
Shell env : off
Providers w/ OAuth/tokens (0): -

anthropic effective=profiles:~/.openclaw/agents/main/agent/auth-profiles.json | profiles=1 (oauth=0, token=0, api_key=1) | anthropic:default=sk-ant-a...oVkuDQAA | env=sk-ant-a...oVkuDQAA | source=env: ANTHROPIC_API_KEY
anthropic-openai effective=env:sk-ant-a...oVkuDQAA | env=sk-ant-a...oVkuDQAA | source=env: ANTHROPIC_API_KEY
google effective=env:AIzaSyB0...AOvPgWlo | env=AIzaSyB0...AOvPgWlo | source=env: GEMINI_API_KEY
ollama effective=profiles:~/.openclaw/agents/main/agent/auth-profiles.json | profiles=1 (oauth=0, token=0, api_key=1) | ollama:default=marker(ollama-local)

OAuth/token status

none

broken hillBOT Apr 18, 2026, 6:59 PM

#

Nice, this pretty much confirms it.

You do have a hosted model available, and it’s authenticated:

sonnet -> anthropic/claude-sonnet-4-6
Anthropic API key is present
tools.profile: "coding" means tools should be available

So the two remaining bad smells are:

defaulting to ollama/llama3.2:latest
stale BOOTSTRAP.md still sitting in the active workspace

If I were in your seat, I’d stop debugging the UI and do this in the shell:

#

mv /array/appdata/openclaw/workspace/.openclaw/BOOTSTRAP.md /array/appdata/openclaw/workspace/.openclaw/BOOTSTRAP.md.bak
openclaw models set anthropic/claude-sonnet-4-6
openclaw gateway restart

Then start a fresh session and test something tiny, like asking the agent to:

read AGENTS.md and summarize it
or read Agent_Creation_Guide.md

Why I’m recommending this:

BOOTSTRAP.md should not still be there after first-run
llama3.2 is a rough primary for tool/subagent debugging
you already have Anthropic auth, so there’s no reason to keep fighting the local model first

#

If you do those 3 steps and it still refuses tools/subagents, paste the next output and I’ll keep digging. But I’m actually optimistic now, this looks fixable.

barren estuary Apr 18, 2026, 7:01 PM

#

while sonnet is setup, i only have a few tokens left so i'd prefer to use a self hosted model. can you recommend a self-hosted model that would be appropriate for 12gb of vram?

broken hillBOT Apr 18, 2026, 7:02 PM

#

Blunt answer, on 12 GB VRAM I would not expect a self-hosted model to be a great primary for OpenClaw tools/subagents.

That VRAM tier is usually fine for:

normal chat
light coding help
simple prompts

It gets rough for:

tool calling
subagents
long context
“do real agent stuff reliably”

So I don’t want to bullshit you with an exact model name here, that changes too fast. For current best picks, ask in #models and check:

#

My practical recommendation:

Use Sonnet briefly to get the stack healthy
bootstrap fixed, tools working, subagents working
Then move back to local for cheap day-to-day chat
Keep hosted as the “when I need tools to actually work” fallback

If you insist on local-only, aim for the largest instruct/coder model you can run stably without aggressive quantization, but go in expecting compromise. On 12 GB, 7B/8B-ish class models are usually where people land, and that’s exactly the range where OpenClaw tool reliability gets shaky.

If you want, I can help you set up a cheap hybrid config next, hosted only when needed, local for everything else.

barren estuary Apr 18, 2026, 7:04 PM

#

this is the prompt i've been trying, do you see anything here that I need to correct?

create an orchestration agent named Hank. Hank will be persistent and will have multiple sub agents. Hank will have his own session to speak with me, and Hank will be responsible for distributing work to his sub agents.

Hank's first subagent is Gemma. Gemma will handle all coding tasks for Hank. Whenever a coding task is needed Gemma will handle it. Gemma will use the qwen-coder7b model.

Hank's second subagent is Raidee. Manny is an expert in Unraid. He knows all the unraid commands and configurations. Whenever there are tasks involving unraid setup, configuration, permissions, or optimization, Manny will handle it. Manny will use the mistral:latest model.

Hank's third subagent is Manny. Manny is an expert in the *arr stack, jellyfin, and qbittorrent. Manny has reviewed all the pages and links in the trash guides https://trash-guides.info/ to become an expert in how to setup and maintain all of these applications. Manny has the ability to inspect each of these docker containers, and request permission to make changes so that they meet the trash guide standards. Manny will create a local markdown file that he can use for a local quick reference, until we can add a rag system. Immediately after being created, Manny will begin auditing the unraid containers

broken hillBOT Apr 18, 2026, 7:05 PM

#

Yeah, a few things in that prompt need tightening.

What I’d correct

You’re mixing “agents” and “subagents”
- a persistent Hank is one thing
- durable specialist workers are another
- in OpenClaw, this is closer to multi-agent config + subagent/session behavior, not “one magic prompt”
The names are inconsistent
- “Hank’s second subagent is Raidee. Manny is…”
- then the third is also Manny
  That alone will confuse the hell out of a model.
It assumes expertise the model hasn’t earned
- “has reviewed all the pages and links in trash guides”
- “knows all the unraid commands”

#

Better: tell it to read/fetch docs when needed, not pretend it already did.

It’s too broad and too write-heavy
- “create a local markdown file”
- “begin auditing containers immediately”
- “make changes so they meet standards”
  That’s a lot to ask before you’ve even proven tools/subagents work.
Per-subagent local model pinning is probably making this worse
- on your hardware, I would not try fancy local model routing first
- get the orchestration flow working first, then optimize model choice

My recommendation

Start much smaller:

get one persistent coordinator working

#

add one read-only coding worker
then add one read-only Unraid/container worker
only later add the media-stack specialist

Better prompt

Create one persistent coordinator session named Hank.

Hank’s job is to speak with me directly and delegate work only when needed.

Rules:
- Default to read-only behavior.
- Ask for approval before any file writes, config changes, or container changes.
- Do not claim prior knowledge from websites or docs you have not actually read in this session.
- Do not start audits automatically. Wait for an explicit task from me.

#

- Keep the system simple: use at most one worker at a time until the workflow is proven.

Worker roles:
1. Coding worker
   - Handles code, scripts, file edits, and debugging.
   - Read-only unless I approve changes.

2. Unraid worker
   - Handles Unraid, Docker, permissions, shares, storage, and service configuration.
   - Start read-only and inspect first.
   - Ask before making any change.

3. Media-stack worker
   - Handles the *arr stack, Jellyfin, and qBittorrent.
   - Use TRaSH Guides only after reading the relevant docs or local notes.

#

   - Start read-only and ask before changing anything.

When a worker is needed, explain why that worker is the right choice.

Also

If you truly want persistent named specialists, read these too:

Because honestly, what you want is part prompt, part config, not just prompt.

If you want, I can help rewrite this into a version specifically for:

single-agent + subagents, or

#

true multi-agent config.

marble mango Apr 19, 2026, 12:10 AM

#

Yeah, make the example for #1 (single-agent + subagents) followed by showing an example of #2 true multi-agent config.

broken hillBOT Apr 19, 2026, 12:11 AM

#

Yep, here’s the clean version.

1) Single-agent + subagents (recommended first)

Use one main agent as Hank. Let Hank spawn workers when needed. Do not try to create permanent named workers from the prompt at first.

Prompt

You are Hank, my persistent coordinator.

Your job is to talk to me directly, plan work, and delegate only when needed.

Rules:
- Default to read-only behavior.
- Ask for approval before any file writes, config changes, docker changes, or system changes.
- Do not claim prior knowledge from docs/websites you have not read in this session.

#

- Do not start audits automatically.
- Use at most one worker at a time until the workflow is proven.

Worker roles:
1. Coding worker
   - For code, scripts, debugging, and file edits.
   - Read-only unless I approve changes.

2. Unraid worker
   - For Unraid, Docker, permissions, shares, storage, and service configuration.
   - Inspect first, then ask before changing anything.

3. Media-stack worker
   - For the *arr stack, Jellyfin, and qBittorrent.
   - Use TRaSH Guides only after reading the relevant docs or local notes.

#

   - Read-only unless I approve changes.

When a worker is needed, explain why that worker is the right choice.

Minimal config shape

{
  tools: { profile: "coding" },

  session: {
    threadBindings: {
      enabled: true,
      idleHours: 24,
      maxAgeHours: 168,

#

    },
  },

  channels: {
    discord: {
      threadBindings: {
        enabled: true,
        spawnSubagentSessions: true,
      },
    },
  },

  agents: {
    defaults: {
      subagents: {

#

        maxSpawnDepth: 1,
        allowAgents: ["main"], // keep it simple first
      },
    },
  },
}

Why this is the better first step

easiest to debug
one workspace
one persona
workers are temporary, not another whole config layer

#

2) True multi-agent config

Use this when you want Hank, Gemma, Raidee, Manny to each have their own workspace, persona files, model, and session history.

Example `openclaw.json` shape

{
  tools: { profile: "coding" },

  agents: {
    list: [
      {
        id: "hank",
        default: true,
        workspace: "/array/appdata/openclaw/workspaces/hank",
        model: "<your-best-tool-capable-model>",

#

        subagents: {
          allowAgents: ["gemma", "raidee", "manny"],
        },
        tools: { profile: "coding" },
      },

      {
        id: "gemma",
        workspace: "/array/appdata/openclaw/workspaces/gemma",
        model: "<your-local-coder-model>",
        tools: { profile: "coding" },
      },

      {
        id: "raidee",

#

        workspace: "/array/appdata/openclaw/workspaces/raidee",
        model: "<your-local-unraid-model>",
        tools: { profile: "coding" },
      },

      {
        id: "manny",
        workspace: "/array/appdata/openclaw/workspaces/manny",
        model: "<your-local-media-model>",
        tools: { profile: "coding" },
      },
    ],
  },

  bindings: [

#

    { agentId: "hank", match: { channel: "discord", accountId: "default" } },
  ],

  session: {
    threadBindings: {
      enabled: true,
      idleHours: 24,
      maxAgeHours: 168,
    },
  },

  channels: {
    discord: {
      threadBindings: {
        enabled: true,

#

        spawnSubagentSessions: true,
      },
    },
  },
}

How this behaves

Hank is the one you talk to
Gemma / Raidee / Manny are separate agent profiles Hank can target
each one gets its own workspace and can have different instructions/files

Important note

On your hardware, I would not try to get fancy with separate local models for all three workers on day 1. Get the routing working first, then tune models.

#

My recommendation

Start with #1.

Once that works:

add one specialist
test it
then graduate to #2

Docs:

If you want, next I can turn this into a real starter config for your Unraid paths instead of placeholders.

barren estuary Apr 21, 2026, 12:32 AM

#

thank you this solved my issue

broken hillBOT Apr 21, 2026, 12:33 AM

#

Glad we caught it 🎉

If this fixed it, please right-click the solution message → Apps → ✅ Mark Solution.

That helps Answer Overflow index it so the next person stuck in Unraid/tool/subagent hell can find it fast. 🦐

#2 months of frustration

What I’d correct

My recommendation

Better prompt

Also

1) Single-agent + subagents (recommended first)

Prompt

Minimal config shape

Why this is the better first step

2) True multi-agent config

Example openclaw.json shape

How this behaves

Important note

My recommendation

Example `openclaw.json` shape