Error when starting Joplin Server docker container on Raspberry Pi

I am attempting to run Joplin Server on a Raspberry Pi 4 (64bit Debian bullseye) for the first time us this this post as my guide:
Guide for Joplin-Server on Raspberry Pi. (Thanks @MrKanister).

I am using the florider89/joplin-server:latest image (Thanks @florider89r).

When I get to Step 8 and run the command:

docker-compose up

I get an error repeated many times:

Starting user_db_1 ... done
Starting user_app_1 ... done
Attaching to user_db_1, user_app_1
app_1  | standard_init_linux.go:228: exec user process caused: exec format error
db_1   | 
db_1   | PostgreSQL Database directory appears to contain a database; Skipping initialization
db_1   | 
db_1   | 2022-02-09 18:11:00.278 UTC [1] LOG:  starting PostgreSQL 13.1 (Debian 13.1-1.pgdg100+1) on aarch64-unknown-linux-gnu, compiled by gcc (Debian 8.3.0-6) 8.3.0, 64-bit
db_1   | 2022-02-09 18:11:00.278 UTC [1] LOG:  listening on IPv4 address "0.0.0.0", port 5432
db_1   | 2022-02-09 18:11:00.279 UTC [1] LOG:  listening on IPv6 address "::", port 5432
db_1   | 2022-02-09 18:11:00.313 UTC [1] LOG:  listening on Unix socket "/var/run/postgresql/.s.PGSQL.5432"
db_1   | 2022-02-09 18:11:00.360 UTC [28] LOG:  database system was shut down at 2022-02-09 17:49:35 UTC
db_1   | 2022-02-09 18:11:00.387 UTC [1] LOG:  database system is ready to accept connections
user_app_1 exited with code 1
app_1  | standard_init_linux.go:228: exec user process caused: exec format error
... repeated many times
user_app_1 exited with code 1
app_1  | standard_init_linux.go:228: exec user process caused: exec format error
...
user_app_1 exited with code 1
app_1  | standard_init_linux.go:228: exec user process caused: exec format error
...
user_app_1 exited with code 1
..
user_app_1 exited with code 1
app_1  | standard_init_linux.go:228: exec user process caused: exec format error
..
user_app_1 exited with code 1
app_1  | standard_init_linux.go:228: exec user process caused: exec format error
...
user_app_1 exited with code 1
app_1  | standard_init_linux.go:228: exec user process caused: exec format error
...
user_app_1 exited with code 1
app_1  | standard_init_linux.go:228: exec user process caused: exec format error
....

This will keep going until I Ctrl+C to stop the process:

^CGracefully stopping... (press Ctrl+C again to force)
Stopping user_app_1 ... done
Stopping user_db_1  ... done

I found another user with a similar issue here:

however it looks like it was an attempt to run on a 32 bit kernel. I am using a 64 bit kernel:

$ uname -a
Linux raspberrypi 5.10.92-v8+ #1514 SMP PREEMPT Mon Jan 17 17:39:38 GMT 2022 aarch64 GNU/Linux

Docker version:

$ docker -v
Docker version 20.10.12, build e91ed57
1 Like

Yes, I can confirm that it is the same for me. An easy fix in that case is to migrate to the "neighboring repository" by @etho201 (nothing against @florider :wink: ): Docker Hub. Hope, that one works out for you.

Kind regards

Oh thanks for the update his is surprising, is the @florider89 image known not to work on the arm64 platform? It looks like there is an arm64 version available for the 'latest' image.

Perhaps you would consider updating your guide so others don't fall into the same problem.

I will try the new image and let you know how it works. Thanks.

No, that has not been the case so far, it has always worked flawlessly (for arm64). I will wait and see how it develops in the next release and change the guide accordingly or not.

Edit: For now I edited the guide to link to this thread if those errors occur.

Oh so it may be a temporary issue then.

I finished the install and got it up and running!

I have two initial questions. How do I get email working, is that a separate configuration? I see there are several email tasks under the admin panel to change the passwords however the emails are not sent.

Also, I created a test account and upload a 1mb file. I then set up syncing to my new server. Under the dashboard->Your account it still shows:

**Total Size** 0 B (0%)

Should this reflect the size of the data in my database?

How can I read the Joplin server logs to see what is going on?

Menu->Logs
Menu->Items
and
/home/joplin/packages/server/logs are all empty.

Finally, how can I access this Joplin Server database?

docker container ls --all shows I have two containers:

  • etechonomy/joplin-server:latest
  • postgres:13.1.

The 'joplin' user is in the joplin-server container but I need that user to login to the database on the postgres container.

$  docker exec -tiu joplin container1_id psql                         
OCI runtime exec failed: exec failed: container_linux.go:380: starting container process caused: exec: "psql": executable file not found in $PATH: unknown
$ docker exec -u joplin container2_id psql
unable to find user joplin: no matching entries in passwd file

Thanks for this tutorial, it was clear and very helpful!

@ioojoplin

It seems that server 2.7.4 introduced a change that did not work with the methods florider and etho201 use to create the ARM versions. etho201 has fixed the issue with their ARM build process.

In this post etho201 explains.

The same thread also has an entry about email. Email is set up using your .env file with all the other Joplin server variables.

It should. Could it be that the amount of data (1MB) is so small that it gets rounded down to zero. Does the sync actually work?

I am not sure what the "logs" section is the GUI is for. I cannot recall ever seeing anything in there. The "items" section used to show the files on the server but I notice that this (and "logs") has been removed from user accounts and only remains available to the admin. I do not use the admin account for syncing so there is no data and I cannot check for you.

docker logs joplin_app_1 will show the log for the Joplin server (assuming your Joplin container is joplin_app_1).

docker logs joplin_db_1 will show a log for the database (assuming your PostGres container is joplin_db_1).

I have no idea and so will leave this question for experts such as @MrKanister :slight_smile:

1 Like

Where does this .env file live? In your docker-compose example you have a section:

app:
        environment:

and then you list some variables. Does an .env file replace this section in the docker-compose file?

Thanks for those threads this really filled in a lot of holes. Perhaps you could put a section in your tutorial near the end mentioning how to check the logs as it is helpful to see if things are working.

I was looking at the env variables in here: env.ts and I see reference to sqlite3 and postgresql. If I do not set the postresql env variables will Joplin use sqlite as the database instead?

Hi @MrKanister, I would like to use the posgresql tools to have a look at how Joplin stores the data inside the database accessing the tools from docker. I am trying to use the Joplin user to authenticate and run a query.

This is my best guess but it doesn't work:

$  docker exec -tiu joplin JOPLIN_SERVER_CONTAINER psql 
or
$  docker exec -tiu joplin JOPLIN_DB_CONTAINER psql 

Do you know if the database tables are encrypted? If not, can that be an option with Joplin server?

I am not sure, it said it synced my test note however the admin dashboard is empty and shows 0%

After I sync to a cloud host I always verify by looking at the data on the host. This is why I would like to look at the database and see if and how it is working.

Not my tutorial :slight_smile:

You can put them with the other server variables under

app:
    environment:

in the docker-compose file.

It does. I mentioned an ".env" file as that is another method that has been mentioned on this forum where the server variables are just stored in a separate file and referenced from the docker-compose file. It's not a better way, just a different way.

If you do not specify a database Joplin server uses SQLite or at least it did when the server was first released! However this was apparently only really suitable for testing.

With regards to looking at the database data @MrKanister's docker-compose file has an entry in the database section that reads:

        volumes:
            - /foo/bar/joplin-data:/var/lib/postgresql/data

This means that the database data is stored outside the database container and on your host RasPi system at /foo/bar/joplin-data (in reality the path you actually chose to store the data). I know nothing about PostgreSQL so I do not know if this could be copied (after stopping the server) and read using some kind of database tool???

If Joplin didn't error during the sync that suggests to me that it is working. If still in doubt you could run Joplin on another machine or VM and connect it to your Joplin server.

1 Like

So sorry for my late answer!

In the admin panel's "items" tab you only see items, that are synced with the admin account. As the normal user accounts don't have this tab (anymore), you can't see the individual files that are synced. As @dpoulton said, if Joplin doesn't throw an error, the sync probably works.


This works exactly how @dpoulton said. If you want to get live logs, just start docker-compose without the -d tag, then you are able to see whether the connections are successful.


I feel very proud, but honestly I don't have a clue either as I've never looked into the database. What I know is, that, as @dpoulton suggested, you are able to shutdown the server and use the /foo/bar/joplin-data/ directory for backups, and potentially for looking into the database.


I don't think I'm gonna do this, as the guide is already quite long. It should also be appealing to people who have no idea about the subject matter, so that the inhibition threshold is lower. The longer the guide, the higher the threshold...I think people who are then interested in the logs will search or ask on their own - like you - in the forum. And there they find for example this thread now. Also, I intentionally wrote that you should start the server without -d tag first, so that you can see logs at least at the beginning.


Did I forgot any questions?
Kind regards :smiley:

1 Like

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.