Community maintained Docker config for the knot server

`KNOT_REPO_SCAN_PATH` doesn't seem to be respected #8

Closed tangled.org
Closed opened by tangled.org

i've been hosting a knot for the past few versions and the latest update to 1.13.0-alpha appears to have changed the directory that repos are scanned in (maybe due to new DID repo resolution?)

the Dockerfile sets env KNOT_REPO_SCAN_PATH=/home/git/repositories and yet it looks like repos are expected to be found under /home/git instead of the repositories subdir as would be expected

client side

$ git fetch origin
repo not found

fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.

relevant docker logs

Accepted publickey for git from [REDACTED-IP] port 47720 ssh2: ED25519 SHA256:Z35UFvFh/+K6juKHjNWq95qtOxmhfhnglMSGDEQzME4
2026/04/27 04:41:17 INFO knot/server/internal: command components handler=Guard components="[cosmichorror.dev knot-docker]"
2026/04/27 04:41:17 DEBU knot: resolve handle DNS handle=cosmichorror.dev err=<nil> did=did:plc:zmzrlti5do46aw3y7jfdzjqs authoritative=false fallback=false duration_ms=33
2026/04/27 04:41:17 DEBU knot: resolve DID did=did:plc:zmzrlti5do46aw3y7jfdzjqs err=<nil> duration_ms=81
2026/04/27 04:41:17 ERRO knot/server/internal: repo not found on disk (legacy) handler=Guard owner=did:plc:zmzrlti5do46aw3y7jfdzjqs name=knot-docker
Received disconnect from [REDACTED-IP] port 47720:11: disconnected by user
Disconnected from user git [REDACTED-IP] port 47720

relevant compose snippet

  knot:
    container_name: knot
    image: knot-dev
    restart: unless-stopped
    volumes:
      - /opt/knot/keys:/etc/ssh/keys
      - /opt/knot/repos:/home/git/repositories
      - /opt/knot/server:/app
    ports:
      - "5555:5555"
      - "22:22"
    env_file:
      - /opt/knot/knot.env

/opt/knot/knot.env

KNOT_SERVER_HOSTNAME=knot.cosmichorror.dev
KNOT_SERVER_OWNER=did:plc:zmzrlti5do46aw3y7jfdzjqs
KNOT_SERVER_DB_PATH=/app/knotserver.db

as you can see no changes to the default KNOT_REPO_SCAN_PATH. is the knot using a hardcoded path instead?

those repos are using my DID as well. trying to push files to a newly created repo appears to use a different DID, but still under /home/git

relevant docker logs

Accepted publickey for git from [REDACTED-IP] port 58446 ssh2: ED25519 SHA256:Z35UFvFh/+K6juKHjNWq95qtOxmhfhnglMSGDEQzME4
2026/04/27 04:32:05 INFO knot/server/internal: command components handler=Guard components="[cosmichorror.dev s3-filehost]"
2026/04/27 04:32:05 DEBU knot: resolve handle DNS handle=cosmichorror.dev err=<nil> did=did:plc:zmzrlti5do46aw3y7jfdzjqs authoritative=false fallback=false duration_ms=1
2026/04/27 04:32:05 DEBU knot: resolve DID did=did:plc:zmzrlti5do46aw3y7jfdzjqs err=<nil> duration_ms=84
2026/04/27 04:32:05 ERRO knot/server/internal: repo not found on disk handler=Guard repoDid=did:plc:tfe6jovthp7kud54nyscwd3z err="repo DID directory not found on disk: /home/git/did:plc:tfe6jovthp7kud54nyscwd3z"
Received disconnect from [REDACTED-IP] port 58446:11: disconnected by user
Disconnected from user git [REDACTED-IP] port 58446

and on the client side

$ git push origin main
repo not found

fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.

Hi! I believe this isn't a 1.13.0 regression in tangled-core, the default has always been /home/git. This repo's default docker-compose.yml sets the env of the KNOT_REPO_SCAN_PATH inline in the environment block, but your compose uses that env_file which doesn't include it, right? Also, seems like the """default""" KNOT_REPO_SCAN_PATH in the dockerfile itself is only in the build step and not the final one, so no good.

deleted all of my other comments to keep them in-thread (still getting used to tangled)

so that fix you linked doesn't actually change anything. i've confirmed that ENV will still be set in later stages

https://docs.docker.com/reference/dockerfile/#env:~:text=A stage inherits


i have reverted my personal knot back to 1.12 and things are working as expected again, so this is most certainly a regression from 1.12 to 1.13

env_file which doesn't include it, right?

passing environment stuff to docker is additive. the only way it wouldn't be included is if i overrode it

actually that dockerfile change does seem to fix things. i'm not sure why the behavior reproducibly changed between 1.12 and 1.13, but oh well 🤷

Sign up or Sign in to add to the discussion.