@laurent do you have any idea why the server is not able to sync and getting the Not Allowed Put (Code 400) error?
1 Like
It would help if you were more precise when reporting bugs. What's the exact Joplin Server version you're using?
1 Like
Unfortunately they don't. People are supposed to know how to use Docker according to their philosophy.
This is why this makes it so dangerous. People who don't use Docker all the time might just use your docker file and think everything will be ok, when they upgrade, but then all their data is gone. I seriously doubt that they go into the postgres container and run daily backups of the database.
1 Like
Yup - only change is that it supports arm64 and the base image is ubuntu, which is slightly lighter. The rest is pretty much the same.
I've updated the tagline of the repo to make it clearer that it's not official.
Sure sorry, how can I help?
I'm not exactly sure where to find the version in Server, but all this is in the last day so I'm assuming all is latest. I saw you guys have an update a few days ago and wanted to stay current.
This is all fresh install stuff, not existing systems.
I can provide the login if it helps.
Sorry, my Docker Knowledge is lacking. I can't keep up with you new programmers, Haha.
Yeah, I'm really struggling with the Docker stuff at the moment. New Tech for me. DevOps!
Docker is an interesting topic.
It makes perfect sense to use Docker for testing and stateless services. But this is only my personal opinion. And I agree there are exceptions to that rule in certain circumstances.
Personally I dislike using backend sytems with persistent storgae requirements in Docker.
It doesn't mean it can't be done or that it is even bad practice. It makes orchestration with k8s and Nomad a bit more complex, since you need (1) a storage solution like Rook or Portworx. Also, I'm old school and come from a performance background. Doing perf tuning on container based systems is often a problem and sometimes very complex (and in rare cases impossible) to accomplish drilling into all the different layers.
A while back I came across "The Docker Book", which is a great resource for starting with Docker. It also includes more advanced topics. I think you can get a PDF copy for 10 bucks or so.
(1): In the meantime most orchestration solutions provide stable (although mostly basic) persistent storage.
2 Likes
Don't wanna nitpick or pretend I understand Docker all that well, but maybe I'll try to point out a difference: the link you posted mentions two options, "writing the database files to disk on the host system using its own internal volume management" and "Create a data directory on the host system". Neither of those is "storing the data in the container."
The "data directory on the host system" is what you'd expect: you say map "/my/local/path" to a location in the container, and that is then used to store files. It looks like "/my/local/path:/path/in/container". (This lets you specify where the files will be, but can sometimes be a bit annoying, since you might encounter issues with permissions etc.)
The "internal volume management" however doesn't refer to storing the data in the container, but in a named volume. Specifying a named volume looks like this: "volume_name:/path/in/container". This basically is a data container, created and managed by Docker, that lives outside the container. The advantages of this approach are that Docker handles everything for you: there usually are no permission errors, and you won't wipe/modify the data by accident. When you upgrade a container, you don't lose data, because the connected volume is not touched when the container is deleted. (The docs say "Volumes are easier to back up or migrate than bind mounts", but when I checked last year, backing them up did not look easy at all. Might be a PEBKAC, though.)
Any of the two approaches is fine; perhaps the volumes are better as a default for Joplin server, because they will most likely just work, and will not require the user to create (and then remember to not delete 
) any folders. On the other hand, just leaving the data in the container is definitely a recipe for disaster, because they will be wiped on each upgrade.
7 Likes
Ah, also - is there any documentation for the Server? I remember installing it by following instructions on some thread (and never touching it again). Is there some doc page?
Sorry if I'm missing something obvious.
1 Like
@florider, by the way I see there's a joplin-server:master image on your Docker Hub page. Is this image somehow automatically generated from the GitHub repo?
This is exactly what I mentioned here Joplin Server pre-release is now available - #18 by tessus and in the following posts. 
Although yours was more elaborate and definitely a nice summary. Cheers.
1 Like
The doc is in the repo: joplin/packages/server at dev · laurent22/joplin · GitHub although I'm not sure if everything is up to date.
1 Like
Oh, one more thing that's unclear to me. What will happen when I upgrade Joplin to 2.0, but leave the server as it is now? Will it work, or just break?
Since I need to access my notes often, on desktop and phone, I only intend to upgrade after the final release is out. So my question is whether I will need to upgrade both at the same time, or may defer the Server upgrade until later.
Good question, and I probably should document this somewhere. If you upgrade to the desktop app v2, you will not be able to sync with Joplin server v1 and vice versa. So if you don't plan to upgrade Joplin Server soon, you should stay on desktop app v1. Same for the mobile and CLI apps.
1 Like
It certainly won't be long until I upgrade.
Speaking of mobile - does that mean that one day, my android app will update to 2.0 and the Server will no longer work?
(Again - no problem with that, just need to know beforehand.)
Yes if the server is still on v1 and the Android app gets updated to v2, it will no longer sync. But I plan to release all the stable v2, including server, at the same time so most likely it won't be a major issue.
sadly not automatically as I haven't figured that piece out yet, but it's basically running off of dev whenever I trigger it.
I wouldn't suggest building a release from the dev branch, or if you really want to do so then perhaps mark it as alpha for example. I try to keep the dev branch relativity stable but it can still have major issues, which are only solved when a release or pre-release is created.
If you name it master, users might think it's relatively stable when it's the opposite of that.
Does anyone have the Client currently working and syncing to JoplinServer?
There's nothing really different about florider's image other than it being compiled to run on Arm64 (for use on a Raspberry Pi or something similar).
You can persist the data on either image (be it official or floriders) by mounting the /var/lib/postgresql/data directory to some place on your host machine:
volumes:
- ${VOLUME_DIR}/joplin-data:/var/lib/postgresql/data
I prefer to do this so that I know exactly where the data is stored, and then I run daily backups with:
docker exec joplin-db /bin/bash -c '/usr/bin/pg_dump -Fc -U joplin joplin' > /mnt/hdd/docker/volume/joplin-data/backup.dump
I then send that backup to cloud storage using rclone. With this setup I feel confident about not losing my notes!
2 Likes