2025-08-28 - A particular note is no longer synchronising

[Coffee]

Operating system

Windows

Joplin version

3.4.6

Desktop version info

Joplin 3.4.6 (prod, win32)

Gerät: win32, AMD Ryzen 7 5800H with Radeon Graphics
Client-ID: 13aa61f6ef06429d9207cc4a953b80e6
Sync-Version: 3
Profil-Version: 48
Unterstützter Schlüsselbund: Ja
Alternative Instanz ID: -

Revision: 4128061

Backup: 1.4.3
Freehand Drawing: 3.1.0
Joplin Calendar: 1.2.0

Sync target

Nextcloud

What issue do you have?

As of today, a specific note in my Joplin 3.4.6 (Prod, Win32) on my main computer is no longer synchronising.
This note synchronises normally on all other Joplin instances (1x Windows, 2x Linux, 2x Android).
There is no ‘Conflicts’ directory.
All other notes seem to continue synchronising normally.
Closing and restarting the app does not help either.
What can I do to get this one note to synchronise again in this one Joplin instance?

[mrjo118]

Try making a change to the note and then syncing. If you do that on the client with the latest change already, the other clients should now receive it. If you do that on a diiferent client, it should receive it on sync, but move the local copy to conflicts

[Coffee]

@mrjo118

If you do that on a diiferent client, it should receive it on sync, but move the local copy to conflicts

Thank you for your reply.

Since all clients except my main client synchronised correctly, I have now tentatively made a test change in my main client.
The result is very strange:
a) The change was synchronised to all other clients.
b) This change overrode all previous changes on the other clients.
c) No conflict folder is visible on any client.
d) A second test change on another client was synchronised again on all other clients.
e) This second test change was again not synchronised back to the main client.
f) In the ‘Previous versions’ I found the overwritten version and saved it with ‘Restore’.

I am considering creating a new entry from this saved version and seeing if it behaves normally again.

[mrjo118]

Check that the time is accurately set on all your devices running Joplin client. It’s possible if one of your devices is a few seconds offset from the real time, then changes made on multiple clients within this time window can end up in the wrong order, i.e. and older changes is considered to be a newer change, instead of creating a conflict

[Coffee]

@mrjo118

Check that the time is accurately set on all your devices running Joplin client.

The time was set to the same time on all systems.
The time is set automatically via a time server.
I don't think it's because of different time settings, because all the other notes were synchronised normally.
I got around the problem with this note by doing the following:
I made a restored older version of this note the new main note.
Like all other notes, this new main note is synchronised cleanly between all clients.
I moved the defective note to a new subdirectory.
Perhaps it will still be useful for something.
I will continue to monitor this and hope that it was an isolated incident that will not occur again.

[_vg]

You could have simply duplicated the problematic note (right click > duplicate), kept the new copy (which should sync fine) and deleted the old buggy copy. In case other notes linked to that note, you would have had to manually update the internal links from the old copy to the new copy. The backlinks plugin would help a lot locating all the notes with internal links to your problematic note.

If nothing else worked, you could have started all over. JEX export, victor plugin etc, see How to fix synchronisation issues and start over

[Coffee]

@_vg

You could have simply duplicated the problematic note (right click > duplicate), kept the new copy (which should sync fine) and deleted the old buggy copy.

That is what I will do first if I encounter something like this again.

[Coffee]

Thank you for your support and for taking the time to help me.
@mrjo118 and @_vg

[Coffee]

@Coffee

That is what I will do first if I encounter something like this again.

As this is the third consecutive day that a note using the profile I've been using since February 2025 has not synchronised with my main computer, I assume there is a fundamental error in the profile itself. All other active profiles on all other clients have synchronised the changes to these notes correctly.

I am therefore starting a new profile (2025-08) on my main computer and resyncing it with the active database in NextCloud.

[Coffee]

@Coffee

I am therefore starting a new profile (2025-08) on my main computer and resyncing it with the active database in NextCloud.

Something is still not quite right.
Shortly before the problems started a few days ago, I changed the logo files in the properties of some notebooks. It was really just a cosmetic change.

Now I notice that these changes are no longer visible in the new profile. Only the new notebook ‘Joplin Plugins’ has the desired logo.

Here is the corresponding view from one of my Linux instances:

I suspect that when I changed the logo files, an error may have occurred in the data, causing my database to become corrupted.

If such phenomena continue to occur, I may actually have to start completely from scratch with an import from a JEX export. Starting afresh from a JEX export also helped me recently when I switched back from JoplinCloud to NextCloud.

[Coffee]

@Coffee

If such phenomena continue to occur, I may actually have to start completely from scratch with an import from a JEX export.

Okay, I'm going to start completely from scratch with a new JEX import, because even in the new profile, a single entry was not synchronised with my Joplin on my main Windows computer.

Plan:
JEX export from a Linux Joplin
New directory in Nextcloud.
New profile 2025-09-01 in all clients.
First import into the new profile on my Linux computer.
Then import into the new profile on my productive Android device.
Etc.

[Coffee]

@Coffee

First import into the new profile on my Linux computer.

By the way:
If you start completely from scratch (with E2EE) by importing a Joplin JEX file, when is the new master.key file uploaded for the first time?
When does it make sense to synchronise other clients with the new data? Only when the first newly encrypted upload from the JEX file has been completely uploaded?

[mrjo118]

@Coffee

By the way:
If you start completely from scratch (with E2EE) by importing a Joplin JEX file, when is the new master.key file uploaded for the first time?
When does it make sense to synchronise other clients with the new data? Only when the first newly encrypted upload from the JEX file has been completely uploaded?

I would do it in this order

1. Create new profile
2. Enable encryption and set master password
3. Import jex
4. Connect sync and sync your changes

I'm going to start completely from scratch with a new JEX import, because even in the new profile, a single entry was not synchronised with my Joplin on my main Windows computer

If you still have your existing Android profile, can you check on the tools > sync status screen that sync items / total items are equal on both sides of the slash under the ‘Sync status (sync items / total items)’ section. If any do not match on both sides, this means there are changes which have not been synced to the server

[Coffee]

@mrjo118

If you still have your existing Android profile

To be on the safe side, I will create new profiles on all devices for that purpose.

I will even delete the new profiles from my Windows and Android devices and recreate them from scratch after the first upload has finished syncing, because Gemini AI told me

If you try to sync other clients before the initial upload is complete, you risk creating synchronization conflicts, as the clients might try to upload old, unencrypted data or create multiple master keys. This can lead to data corruption and a lot of headaches.

[mrjo118]

@mrjo118

can you check on the tools > sync status screen that sync items / total items are equal on both sides of the slash under the ‘Sync status (sync items / total items)’ section. If any do not match on both sides, this means there are changes which have not been synced to the server

@Coffee Did you check this on the original profile of your Android client? Would you be able to post here the results for the sync status?

[Coffee]

@mrjo118

Did you check this on the original profile of your Android client? Would you be able to post here the results for the sync status?

I still have the old profile on my productive Android client, which uses the storage space with the presumably corrupted data.
To answer your question, I restarted this profile today.
As expected, there was a synchronisation process during which the now outdated note versions were deleted.
After completing this synchronisation process, I took the following screenshot:

[mrjo118]

Ok, thanks. Well that rules out out of sync items on your Android client, so not really sure what else could be cause.

Please do post back after you have reset everything from scratch for the problematic profile on all your clients, when you have determined whether or not that resolves the issue.

[Coffee]

@mrjo118

Please do post back after you have reset everything from scratch for the problematic profile on all your clients

I would like to give a brief initial response at this point. So far, everything looks good with the new profile for the new storage space in NextCloud. However, I would like to observe this for a while longer before completing the process.

I would also like to briefly report on my experience with importing JEX files from my top-level folders in batches.

Importing and synchronising my various apps installed on Windows and Linux was quick, taking what felt like one to two days. Synchronising the new profile of my already installed Android app on my Samsung S23 was also successful within two to three days.

Only the synchronisation with the new profile in the app, which was completely newly installed on my Samsung S10 on 5 September 2025, was completed late yesterday evening, 12 September 2025. I first had to learn that this installation only showed a result after about 45 minutes when querying the synchronisation status.

I'll be back “soon” with more on this...

[Coffee]

@mrjo118

when you have determined whether or not that resolves the issue.

I would like to observe this for a while longer before completing the process.

[Coffee]

@mrjo118

Please do post back after you have reset everything from scratch for the problematic profile on all your clients, when you have determined whether or not that resolves the issue.

Summary: The problem has been solved.

I had practically no more problems of this kind for about two weeks.
Therefore, I consider this action to have been basically successful.
There was only one other noteworthy problem, which I was able to fix manually.

Further details:

Presumed root causes/observations:
In very most cases, exporting and importing JEX data into new databases with new profiles eliminates problems with inconsistent data. However, there remains the possibility that individual notes may somehow remain inconsistent despite JEX export and import. These isolated cases can be identified with a little attention, and the data can be manually rescued and inserted into a new note.

So far there was only one problematic note in my database that originated from earlier JoplinCloud days. It was shared between different JoplinCloud IDs. I was only able to save its content by sharing the Markdown code directly to my Nextcloud using the share function in my Joplin Android app. It could not be transferred using WhatsApp, nor was it synchronised by Joplin.

Forecast for data quality:
I may encounter isolated instances of further problematic notes in my database that originate from earlier JoplinCloud times and were shared between different JoplinCloud IDs.

Observations and considerations on the topic of JEX export and import

Since you should always wait for the complete JEX import and its full synchronisation before starting the synchronisation of further profiles from other devices when restarting with JEX export and import, it takes a very long time with my database before I can start again. I have about ten folders at the top level in my database. In order to be able to start synchronising additional devices more quickly, this time I performed a separate JEX export for each top-level folder and started the JEX import with the folder containing the least amount of data. The first synchronisation of the first JEX import was completed successfully and quickly, and I was able to start synchronising additional devices without encountering any problems. While I was importing the next JEX file, synchronisation with my second device was already running. This allowed me to reduce the total runtime for the complete restart. However, this approach seems to have one disadvantage: not all Markdown links to other notes are provided with the correct new object IDs. This probably only works for notes that are in the same imported JEX file. Since most of my Markdown links remain within my top-level folders, I have only had to trace and recreate two Markdown links so far by searching for the corresponding text string.

If I ever have to start completely from scratch again from a JEX data backup, I will try the following procedure: On the one hand, I want to be able to quickly start synchronising additional devices, and on the other hand, all Markdown links should be correctly assigned new object IDs.

a) Start a new database with new profiles.
b) Create and synchronise a new temporary folder with a new temporary note.
c) Connect additional devices and synchronise this temporary note.
d) Re-import the complete JEX export.
e) Delete the temporary folder with the temporary note.