Cannot register device

[yaro24]

I wanted to try openSOHO out but am failing to add any devices.
I'm running docker 0.7.1

Tue Sep 16 12:16:41 2025 daemon.err openwisp: Registration failed! {"data":{},"message":"Registration failed!","status":400}

tried it with multiple different Clients

[yaro24]

no idea why, but running 0.7.1 from the release zip works fine.
In the logs I can see:
Update Device health
Failed to update device health
SQL logic error: no such table: devices (1)

[rubenbe]

Hmm, interesting. It might put the migrations in the wrong directory and thus not creating any collection (including the devices collection)
Can you try something like this? Do run from an fresh data directory. In case you use docker, use that instead of podman.

podman run -e OPENSOHO_SHARED_SECRET=x -p 0.0.0.0:8090:8090 --workdir=/ko-app --volume $PWD/data:/ko-app/pb_data:z ghcr.io/opensoho/opensoho:v0.7.1 serve  --http 0.0.0.0:8090

[dekarl]

--workdir=/ko-app

that appears to be it (I did not mount a volume, so its always empty)

$ docker run -e OPENSOHO_SHARED_SECRET=x -p 0.0.0.0:8090:8090  ghcr.io/opensoho/opensoho:v0.7.1 serve  --http 0.0.0.0:8090
Unable to find image 'ghcr.io/opensoho/opensoho:v0.7.1' locally
v0.7.1: Pulling from opensoho/opensoho
9824c27679d3: Pull complete 
198376d12334: Pull complete 
b96b42a58b0e: Pull complete 
Digest: sha256:1b74744468d95f369de334f1b958f88ea6946a946147e9a0fc426a45e6205c47
Status: Downloaded newer image for ghcr.io/opensoho/opensoho:v0.7.1
2025/09/17 05:55:15 Server started at http://0.0.0.0:8090
├─ REST API:  http://0.0.0.0:8090/api/
└─ Dashboard: http://0.0.0.0:8090/_/

(!) Launch the URL below in the browser if it hasn't been open already to create your first superuser account:
http://0.0.0.0:8090/_/#/pbinstal/eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJjb2xsZWN0aW9uSWQiOiJwYmNfMzE0MjYzNTgyMyIsImV4cCI6MTc1ODA5MDMxNSwiaWQiOiJoZW00eWhlYnUzamFyamYiLCJyZWZyZXNoYWJsZSI6ZmFsc2UsInR5cGUiOiJhdXRoIn0.KcQqkYJ4ITq_NQdIzvI97rww24Ylcny0Y2SYPk9M2mo
(you can also create your first superuser by running: /ko-app/opensoho superuser upsert EMAIL PASS)

Update Device health
Failed to update device health
SQL logic error: no such table: devices (1)

vs.

$ docker run -e OPENSOHO_SHARED_SECRET=x -p 0.0.0.0:8090:8090 --workdir=/ko-app ghcr.io/opensoho/opensoho:v0.7.1 serve --http 0.0.0.0:8090
2025/09/17 05:57:02 Server started at http://0.0.0.0:8090
├─ REST API:  http://0.0.0.0:8090/api/
└─ Dashboard: http://0.0.0.0:8090/_/

(!) Launch the URL below in the browser if it hasn't been open already to create your first superuser account:
http://0.0.0.0:8090/_/#/pbinstal/eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJjb2xsZWN0aW9uSWQiOiJwYmNfMzE0MjYzNTgyMyIsImV4cCI6MTc1ODA5MDQyMiwiaWQiOiJyYjJpY3FwNjN0YTJxa2UiLCJyZWZyZXNoYWJsZSI6ZmFsc2UsInR5cGUiOiJhdXRoIn0.Dojham_X6MM2qqmj5J4tZbrgRUiINcBEo0VHUtz8418
(you can also create your first superuser by running: /ko-app/opensoho superuser upsert EMAIL PASS)

Update Device health
Update Device health

[rubenbe]

I'll have a look at how the migrations dir is found, there is probably an issue somewhere, where opensoho is not run from its own directory.

[yaro24]

building the docker image myself with the provided dockerfile and running it in docker compose works as well
Is the published image built differently in any way? Couldn't find it in the actions

[rubenbe]

Yes indeed, the Dockerfile is not used to build the released images (goreleaser does that using "ko").
I agree that's confusing and their behavior should better align.

Currently they are not yet built on github itself (if you know a quick walkthrough on how to do that, do let me know ;) )
At this moment, both the binaries and the images are built on my local PC, but for the sake of transparency it would be better that the build is "public"

[rubenbe]

@yaro24 (@dekarl) Could you try release v0.7.2 ? This should fix the issue with the paths

[dekarl]

That looks like an oversight in pocketbase that you only have either JS migrations as external files or GO migrations embedded into the executable. But you can't hand JS migrations in an embedFS to the JSVM to read them from there...

cwd is /

getting the directory containing the currently running executable is also possible (StackOverflow). not sure if that is needed, though.

You could tell ko to put pb_migrations directly into the image, so you don't have to extract them on startup.

	// MigrationsDir specifies the JS migrations directory.
	//
	// If not set it fallbacks to a relative "pb_data/../pb_migrations" directory.

e.g. if KO_DATA_PATH is set, then read from KO_DATA_PATH/pb_migrations instead of extracting, then re-reading...
https://ko.build/features/static-assets/

And also set the DataDir to /pb_data and mount a volume to /pb_data. Also mount the image readonly, so you notice when data is written outside of the volume mount... (avoid surprising data loss)

$ docker run -e OPENSOHO_SHARED_SECRET=x -p 0.0.0.0:8090:8090 --read-only  ghcr.io/opensoho/opensoho:v0.7.2 serve  --http 0.0.0.0:8090
2025/09/17 19:52:07 mkdir /pb_migrations: read-only file system

$ docker run -e OPENSOHO_SHARED_SECRET=x -p 0.0.0.0:8090:8090 --read-only --volume $PWD/data:/ko-app/pb_data:z --tmpfs /pb_migrations  ghcr.io/opensoho/opensoho:v0.7.2 serve  --http 0.0.0.0:8090
2025/09/17 19:58:14 mkdir /pb_data: read-only file system

That would fit well to Kubernetes, too. I can adapt the chart to work with an image using KO_DATA_PATH. Then the Dockerfile can be removed to not confuse users.

[hoernrob]

@yaro24 (@dekarl) Could you try release v0.7.2 ? This should fix the issue with the paths

can confirm 0.7.2 is working

[rubenbe]

Yes indeed (largely):
I was thinking to add a mechanism to support js migrations from the binary. But in the end I didn't. Pocketbase does not store the entire migration inside its database, but only the filename. So if someone would like to downgrade (not yet supported!), it is useful to have the files there on the filesystem to attempt a rollback.

The main reason to keep the migrations inside the binary and extract them is the ease of deployment for users of the bare binary.

After writing this: maybe pb_migrations should also be a required volume mount 🤔

[yaro24]

After writing this: maybe pb_migrations should also be a required volume mount 🤔

(or another folder in the data directory to have it all in one directory)

[rubenbe]

(or another folder in the data directory to have it all in one directory)

True, good idea

[dekarl]

The main reason to keep the migrations inside the binary and extract them is the ease of deployment for users of the bare binary.

After writing this: maybe pb_migrations should also be a required volume mount 🤔

The migrations are not that big, which is where the idea of "just have them in the binary and directly in kodata in the image" came from. Then you have a clean data valume with only the content of pb_data and can switch the source of the migrations by looking for the KO_DATA_DIR environment variable.

Also simply setting the pb data dir hard to /pb_data in that case results in an image that is predictable.

[rubenbe]

@dekarl Hmm, that KO_DATA_DIR is indeed a convenient and easy-to-detect method. I'll have a look, thanks!