Issue with synchronising different user profiles in one Joplin instance

I’ve been using Joplin as a notetaking app for a while now and synchronising the contents with my own Nextcloud instance. I recently found out that Joplin supports multiple profiles and I created several additional one, each of which I wanted to synchronise with a separate Nextcloud user account. After I set up the sync all profiles synchronised perfectly on the macOS client of Joplin, but it turned out that on the Android client only one of the profiles would sync properly while the additional ones produced errors (see screenshot). After some more testing I came to realise that the working sync is always with the first active profile after a reboot, and that every profile I switch to fails the sync. I’m not sure if this issue is caused by Joplin or by Nextcloud, so I’m posting to inquire with both communities. Any ideas and feedback are greatly appreciated.

1 Like

As long you sync each single account well there is no reason to assume something is wrong with Nextcloud. Likely the problem is related to Joplin (mobile) as you state all accounts work well as long it is the first one.

1 Like

I had the same problem and have been through an odyssey of several months for this reason.
I ended my two attempts with self-operated instances of Nextcloud and am now with a provider for Managed Nextcloud.
There I bought two productive instances and got a third test instance from the provider for free, so that I can use it as a test environment exactly and only for this problem. So far I have been able to reproduce the problem again and again. I also provided two accounts of this test instance to the Joplin developers so that they could reproduce the problem themselves. As @moontan described, the problem only occurs between NextCloud and Joplin Android apps in which multiple Joplin instances are configured. I do not have this problem with Joplin apps on Windows or Linux. The Joplin Android app with multiple profiles does not have this problem with other cloud solutions besides Nextcloud either.

In my professional environment, I have years of experience troubleshooting network connections between systems from different developers or different operators. In this case, I have come to the conclusion that I do not have the time and energy to find and involve the experts I consider necessary to solve this very specific problem. As a Joplin newbie, it took me several months to convince the experts on the Joplin forum that it was not a simple user error on my part. It would take me more time and energy to build up a sufficient reputation here in the Nextcloud community.

For this reason, I have migrated the data of my productive Joplin instances to the Joplin Cloud myself. There, this problem with the Joplin Android app with multiple profiles does not exist. And if there are problems, I can always contact the Joplin experts, as they develop and operate both the Joplin apps and the Joplin Cloud.

But I still find this problem annoying. I like both Nextcloud and Joplin as open source projects and I would like to see this problem solved in the combination.

After moontan announced in the Joplin community that he had presented this topic here in the Nextcloud community, I would like to try to see if we can’t succeed in analysing this problem together in the necessary depth, finding the root cause and solving the problem in future versions.

What I can offer is the joint use and analysis of the Nextcloud test instance of my Managed Nextcloud operator and a certain amount of coordination and moderation work between the experts from all the parties involved - Joplin developers, my Managed Nextcloud operator and - what I still lack - the Nextcloud developers who are able to analyse the logs in the Nextcloud test instance in the necessary depth. My Managed Nextcloud operator has already said that he does not see himself as being able to carry out these analyses and also does not have sufficiently good contacts with the Nextcloud developers.

My question is therefore whether there are any Nextcloud experts who would be willing to participate in this tricky collaborative troubleshooting if my Managed Nextcloud operator were to give them access to my Nextcloud test instance.

I am not a developer and never will be. My amateur understanding of this problem is that it is a problem with the correct assignment of the credentials of the different profile users at the WebDAV interface. From the point of view of the Joplin Android app, it seems that when switching from the first to the second profile, it passes the correct credentials of the second user to the Nextcloud server, but the server denies access to the corresponding subdirectories or claims that they do not exist. One of the two sides (WebDAV stack on Android or WebDAV stack on the Nextcloud side) does not process the change of credentials correctly.

We are therefore looking for Nextcloud experts to try to extract the relevant logs from the Nextcloud side - if necessary by activating verbose mode.

1 Like

A theory that I think is worth exploring, I try to describe in the following words:

In the case of NextCloud, it is often also about nginx. When Joplin connects to a Nextcloud, Joplin uses a WebDAV stack. In this combination, there was already a problem that was solved with a workaround in Joplin (*)

After restarting Android - Joplin / after a reboot of Android, this collaboration works.
After switching from one Joplin profile to another Joplin profile, this collaboration does not work.
Why is that?

Could it be that when switching from one Joplin profile to another, not all variables that are sent to the server by the WebDAV stack are properly reset?

Is it possible that when changing profiles, an existing WebDAV connection is not properly terminated and the Nextcloud server therefore implicitly assumes that the next data still refers to the other profile?

Is there a way to ensure that the WebDAV stack is reliably reset to the same clean state it would be in after a reboot of Android, even when switching profiles, using a command or procedure in the Joplin code of the Android app?

(*) I would like to mention the following sources of my research in this context:

https://trac.nginx.org/nginx/ticket/1966

**Description]**
Some WebDAV clients that create collections do that without including the trailing slash. The logs offer no further explanation, and to a casual user the 409 error is confusing (as it indicates that the parent collection is absent).
RFC4918 recommends them to have a trailing slash, but given that several applications don't send a trailing slash, it stands to reason that it's common for servers to accept it. Section 5.2 even gives concrete guidance that in such a case, the server should accept and send a Content-Location header ("There is a standing convention").
Example clients that don't are webdav-js (​https://github.com/dom111/webdav-js) and Stratospherix FileBrowser for Business; **some examples are around for other clients that employ workarounds** (eg. ​https://github.com/laurent22/**joplin**/issues/523).

and

laurent22 commented Jun 14, 2018 in GitHub
@ bradmcl, your fix should be part of the latest releases (Desktop and Android) so I guess we can close this issue?

Addendum 4 August 2024:
Meanwhile, it is suspected that the problem is related to the use of cookies in the WebDAV API.
Joplin itself does not use or set any cookies.
On Android, Joplin uses okhttp - and okhttp probably sets cookies itself, which leads to this problem when switching from one Joplin profile to another.
There might be a workaround by having Joplin send a “delete cookies” command before each request ( please excuse my amateurish wording ).
It might help the Joplin experts if we understood exactly what NextCloud does with the cookies in their WebDAV API.
Can someone provide us with such a description?

The problem that the Android Joplin app had when multiple profiles with different usernames were used on the same NextCloud instance has been fixed with Joplin mobile 3.3.8.

1 Like

This topic was automatically closed after 28 days. New replies are no longer allowed.