I'm using this note for more than a year now.
using the sync for 3 devices. It was good, fast for the few first months.
As notes began to increase, started to have conficts.
Then started to delete my notes.
At the first, I just restored the notes by the date, but now I can't even know when what wase deleted. You should make it not delete notes by itself and make the user to recover it by their own. I'm sick of this app and never going to use this again.
Caution : Do not use joplin for important notes. It can be lost in any time.
I'm returning to Joplin…thought I'd use Emacs and some of its packages, but leaving Emacs ecosystem for now.
Today had a look at TriliumNext, installed LogSeq, Obsidian, Qownnotes…but Joplin's interface is simply the most convenient for me. It allows me to use my preferred external editors and its web clipper is exceptional!
Now I'd like to (again) support the development by using Joplin Pro cloud service and wonder if that service is (more) secure in regarding to deleted notes?
Don't use Dropbox. They lost my data and hung me out to dry even though I was an early adopter who referred almost 100 people to their platform. I walked away from my decade-old account with gigs of free referral bonus space because they lied to me and refused to try and get my data back.
I am a huge fan of Joplin but sync has become an issue for me after I switched to a new phone. My total JEX size is 430Mb. I sync via webdav and I documented some of the issues I had here:
Today I decided to re-try getting sync over webdav working on my laptop. I retired my old webdav server and started with a new fresh webdav on my Nextcloud instance. I created an empty folder and set up the webdav endpoint in Joplin settings. I clicked "sync" and immediately it says: "remote deleted" with the number going up and up. What could it possibly be deleting on the remote when it's a completely empty folder? Shouldn't it be creating files on the remote not deleting them? Is it deleting other files from my server? I checked on the server and there are various lockfiles and info.json created there. I looked at the client log and I saw something about "local deleted" so I immediately stopped it.
Even if this is expected behavior it's really badly communicated. People's data is important to them and having the first initial sync to a webdav remote start deleting files completely eliminates any confidence I had in Joplin, especially after the experiences I had trying to get it to sync to my phone, with duplicate files created after I import the JEX.
I'm at a loss now because I really like the Joplin interface and I don't want to switch to a proprietary solution like Obsidian, but I no longer have confidence that Joplin is taking care of my data. It's a bit frustrating.
Yeah. True. Its interface is good. But looks like it needs more setting options to prevent data loss. Maybe it's because I'm using windows and Linux together.
The thing is that many of these issues is confusion from incorrectly setup self-hosted servers and using free, throttled and unreliable cloud storage for important documents.
We put in huge efforts to try to prevent users from shooting themselves in the foot, but there's only so much we can do if we don't control the server. Those issues don't happen with Joplin Cloud (or a lot less frequently) because we control both client and server and can ensure that the sync experience goes smoothly.
Experienced users who know how to properly manage a server also don't have any issue, but we don't hear about them here.
Experienced user here. Never had sync problems between Joplin and self-hosted Nextcloud for a year already. And even if I did - there's backup plugin or external sync.
Joplin is guilty here... of being nice and try to support lots of backend while offering users a footgun.
I am using joplin server locally and there is nothing wrong with the sync so I would not blame Joplin nor its support of lots of backen file storage solutions.
Instead you may want to reconsider what backend you offer to Joplin for it to work well.
Regarding the "deleting remote items" on initial sync, see this comment. Likely nothing to worry about, and just poor messaging from the application: Unexplained Deleted Files - #2 by personalizedrefriger?
I am seeing this on a fresh sync to an empty folder in Nextcloud webdav. For what possible reason would it be starting the sync by deleting items? Shouldn't it copy items up first and then delete the expired histories?
To all the people here doing user-blaming and saying it's the fault of the sync setup and "never had sync problems" etc. - that's cool, just be aware that Joplin will certainly lose users with this type of attitude. There is at the very least a messaging problem in the app, and at worst actual bugs and problems with the sync. Some facts:
I am an experienced user who knows how to properly manage a server (developer myself). Yes, you're hearing from me here.
My Nextcloud instance is configured properly.
I followed the config exactly as documented when setting up the sync.
I had sync working great for years to a from my desktop and phone to a webdav server.
Concrete problems I had when I got a new phone:
Initial sync is very slow (maybe not the app's fault but it seems like sync'ing 400mb of data in 2025 should not take so many hours).
Initial sync told me it was deleting hundreds of items with no explanation of why or what it was doing.
That scared me so deleted Joplin on my phone. I restarted by copying the JEX from desktop to my phone to see if I could avoid the slow sync that way (I wish this was a solution by the way).
I encountered bugs with the JEX import on Android (as documented on GitHub and since working/fixed - I got the JEX imported).
Once I got the JEX import working on my phone I enabled sync to webdav and discovered the extremely surprising behavior of files getting duplicated because Joplin didn't recognize the file in the JEX is the same as the file in the webdav. This was frustrating and unexpected and I now have all these duplicated files that I can't delete because I don't know if deleting it will delete it from sync. I think this could be improved by checking if a file is obviously the same (e.g. the hash, or using UUIDs or whatever).
Again I experienced scary delete messages with no explanation of why it is deleting files.
I guess now that I know that these deletions at the very start of sync are expected I will try the sync to webdav again (after doing a local backup) and just put up with the day long sync to my phone and the scary "deleting file" messages.
Things I think the Joplin devs could focus on:
Make the messaging about deletes much clearer. Explain to the user exactly what and why it is deleting.
Before running a sync for the first time pop up a message asking "Have you made a local JEX backup in case something goes wrong?"
I noticed this button: "Re-upload local data to sync target". Why should the user care about this? Shouldn't Joplin detect an empty sync target and just do this automatically the first time?
Work on optimizing sync. Other apps e.g. git can sync 400mb without spending a whole day on it. I realize this is a big ask and probably a lot of work has been done on this already, but it's probably possible to do better. I also realize this may just be an artifact of webdav being a slow protocol. If that's the case maybe the messaging can be better in the apps, e.g. saying "your data is 400mb and this can take up to 24 hours to sync over webdav" or something like that.
Update: see below for a couple more suggestions for improving sync.
I love Joplin. It's served me really well. I am a paying sponsor of the project. I am a highly technical and experienced user. I'm super grateful for this Free Software. I also think some of these things can be improved in Joplin.
Another thing that could improve the user experience: show the number (even an estimation) of items that still need to be sync'ed. At the moment I see 2725 items - but out of how many? This is a replace-remote-with-local so you know the destination is empty and every file must be sync'ed. You could also time each item and then provide a rough estimate. Yes, I understand there could be technical challenges with this due to the current implementation, but obviously it is possible because it happens in other apps.
@laurent It looks like a cool product and I wish you luck with it. I don't want to sync to somebody else's server. I donate more than a Pro subscription every month via GitHub so it's not about the money. My self-hosted webdav servers are also not free. They cost more per month than a Joplin Cloud subscription. For an open source Free Software app like Joplin it seems like a good idea to have well supported fully self-hosted sync as a feature.
A perfectly reasonable response to what I've written above would be "Ok, so implement these things yourself and open a PR." That is what I would also say as a developer who works in open source when somebody comes asking for complicated features. I acknowledge that I am creating work here.
The reason I am documenting these issues anyway is if you don't want to see posts on the forum with the title "Very disappointed on Joplin and its sync problems" then I think you can and should improve sync. You can do what you want with this information. If it's not important to you, then all good. I and others like me will keep looking for alternatives when self-hosted sync works badly.
I want to re-iterate that I am incredibly grateful for Joplin and my years of use of it, and that is why I sponsor.
I'm using joplin for a couple of years now and had switched very early to a selfhosted joplinserver. I only had once a little dataloss, that was absolutely my fault. I was experimenting to update the database container without a backup... "deduuh..."
I've never experienced a failure or dataloss with this sync method.
At first I tried to save some money by syncing with pcloud. But this is not support because of the faulty webdav implementation on pclouds side. So I don't tried other synchronisation options from this point on.
I think there's a difference between what we do here, providing support, improving the apps based on user feedback, etc. and "user blaming" but ok.
I think in your case the problem, as chevdor mentioned above, is the app allows too much and gives too much information and that can be confusing. We try to hide the more advanced function and to document them but we can't always guess everything users are going to think and do.
Maybe we should put a big warning above export/import functions saying that it is not the same as sync and that, by design, IDs are changed... or maybe not... I think part of being involved in a relatively popular project like this one is that you have to accept that you can't get everything right, and sometimes by trying to improve something you end up making it worse or more confusing.
I've spent countless hours over the last few months following and analyzing every issue I could find on Github and the forum related to data loss, and I've submitted a couple of PRs which fix and prevent some of the issues, which were accepted into the codebase. While there are remaining issues of some rare cases that note content can get overwritten by another note (which can be recovered via note history), the only other instances of data loss I have seen for Joplin server / cloud at no fault of the user are the following 2 open issues, which only relate to notes which have been shared:
I also think some of these things can be improved in Joplin.