Download Free CE

SynapCores v1.8.6.1 — Docker EMBED works out of the box again

Published on June 18, 2026

SynapCores v1.8.6.1 — Docker EMBED works out of the box again

If you ran SynapCores Community Edition in Docker any time between June 11 (when v1.8.1-ce shipped) and today, and you tried SELECT EMBED('hello world') on a fresh install, you hit this:

Query operation error: Batch error: AI error: Embedding generation failed:
  Provider error: auto-pull failed for 'all-minilm:latest':
  io error at Some("/opt/synapcores/aidb_data/./models/manifests"):
  Permission denied (os error 13)

It looks like the engine. It isn't. It's a one-line Dockerfile.community-runtime mistake that made the published Docker image's model-cache directory unwritable to the synapcores user the engine actually runs as.

Six tags shipped with this bug: v1.8.1-ce, v1.8.2-ce, v1.8.3-ce, v1.8.4-ce, v1.8.5-ce, v1.8.6-ce. None of them survived the documented docker run recipe — neither the no-volume form ("just docker run") nor the named-volume form ("-v synapcores-data:/var/lib/synapcores" from the Download page). The named volume inherits ownership from the image on first use, so the volume didn't fix the bug; it copied the bug into the volume.

v1.8.6.1-ce is a one-commit Docker fix. Engine binary is unchanged from v1.8.6-ce. If you've been hitting this, upgrade and the first EMBED call works.

What was wrong

The Dockerfile created the registry blob directory like this:

RUN install -d -m 0755 -o synapcores -g synapcores \
    /opt/synapcores/aidb_data/models/blobs

install -d only sets ownership on the final path component. If a parent dir doesn't exist (models/ here), install -d creates it on the fly, but inherits the RUN step's effective uid (which is root, because Dockerfile RUNs are root) and the process umask.

So after the build:

/var/lib/synapcores                drwxr-x---  synapcores:synapcores   ← OK
/var/lib/synapcores/cache          drwxr-x---  synapcores:synapcores   ← OK
/var/lib/synapcores/models         drwxr-xr-x  root:root               ← WRONG
/var/lib/synapcores/models/blobs   drwxr-xr-x  synapcores:synapcores   ← OK but inside root-owned parent

The engine boots as synapcores, calls mkdir -p models/manifests/ to bootstrap the registry, and the mkdir errors with EACCES because the parent (models/) is root-owned and group-other has no write bit. Every auto-pull through the native model registry — all-minilm:latest for EMBED, qwen2.5-coder:7b for AGENT_RUN / GENERATE — fails the same way.

The fix

Explicitly chown each level. One line becomes three:

RUN install -d -m 0755 -o synapcores -g synapcores \
        /opt/synapcores/aidb_data/models \
 && install -d -m 0755 -o synapcores -g synapcores \
        /opt/synapcores/aidb_data/models/blobs \
 && install -d -m 0755 -o synapcores -g synapcores \
        /opt/synapcores/aidb_data/models/manifests

Now all three directories ship as synapcores:synapcores 755 and the runtime user can write into them on first boot.

Why we missed it

Mostly: the release canary tested with a pre-mounted volume that already had the right ownership from a previous run, so first-boot auto-pull never ran clean against the actually-published image. We've been validating "the engine works" without validating "the documented docker run recipe works against the published image." Different gates.

Our internal release skill does call for a published-artifact canary using the documented operator config, with no env shortcuts. It got skipped (or short-circuited) on every v1.8.x release after v1.8.0 because the team rotated through different validators and the gate became implicit. We're fixing the process side of this in parallel — turning the published-image canary into a CI job that runs the homepage's actual copy-paste recipe and asserts EMBED returns a vector, not an error.

Validating v1.8.6.1

End-to-end on an Intel i5-10400F (no AVX-512), against the actually published image, using the exact snippet from the Download page:

docker run -d --name synapcores \
  -p 8080:8080 \
  -e AIDB_ACCEPT_LICENSE=1 \
  -v synapcores-data:/var/lib/synapcores \
  synapcores/community:v1.8.6.1-ce

-- First EMBED call against a fresh container
SELECT EMBED('hello world') AS v;
-- → 384-dim vector, all-minilm:latest auto-pulled in the background

-- Cross-feature end-to-end
CREATE TABLE docs (id TEXT PRIMARY KEY, content TEXT, embedding VECTOR(384));
INSERT INTO docs (id, content, embedding)
    VALUES ('d1', 'wireless headphones', EMBED('wireless headphones'));
SELECT id, COSINE_SIMILARITY(embedding, EMBED('earbuds for jogging')) AS score
  FROM docs ORDER BY score DESC LIMIT 1;
-- → ("d1", 0.47)

All probes green. qwen2.5-coder:7b (4.4 GB) also auto-pulls without EACCES — AGENT_RUN and GENERATE work OOB too.

Also carried in this release

v1.8.6.1 ships with the v1.8.6 engine commit, so the #388 negative-value array-literal fix from yesterday's v1.8.6 release also lands here:

-- v1.8.5 and earlier: ❌ "Array elements must be literal values"
-- v1.8.6 / v1.8.6.1: ✅ works
INSERT INTO embeddings (id, vec)
    VALUES ('doc-1', [-0.0234, 0.0871, -0.1502, /* ... */]);

Every real ML embedding (HuggingFace MiniLM, OpenAI text-embedding-3-small, Cohere) has ~50% negative components, so this was effectively blocking every SQL VECTOR(N) write against a real embedder. Read more in the v1.8.6 release post (still up; v1.8.6's tag remains for traceability, v1.8.6.1 supersedes it for Docker users).

Try it

# Docker (homepage Download page recipe)
docker run -d --name synapcores \
  -p 8080:8080 \
  -e AIDB_ACCEPT_LICENSE=1 \
  -v synapcores-data:/var/lib/synapcores \
  synapcores/community:v1.8.6.1-ce

# Binary install (Linux x86_64 / aarch64 + Ubuntu 24 builds, macOS aarch64)
curl -fsSL https://get.synapcores.com | sh

# Pin to v1.8.6.1-ce explicitly
curl -fsSL https://get.synapcores.com | SYNAPCORES_VERSION=v1.8.6.1-ce sh

Upgrade is in-place — no data migration. If you previously worked around the bug by docker execing in and running synapcores pull all-minilm:latest by hand, you don't need to anymore; the auto-pull just works.

Full reference: docs.synapcores.com/releases/v1.8.6.1-ce · GitHub release.

Bugs, requests, "you sure you got it this time?": github.com/mataluis2k/aidb/issues.

— The SynapCores team