Android
2.14.9
2.14.22 (prod, darwin)
Nextcloud
Markdown Editor
Nextcloud sync on Joplin Android fails for all but the default profile. See screenshot for details on the error messages. Syncing with the same Nextcloud instance works perfectly for all profiles on the macOS client.
syncReport-1717980995793.txt (1.95 MB)
Just upgraded the Nextcloud Server to Nextcloud Hub 8 (v29) and the issue persists.
I would be really happy if someone could at least speculate about what causes this behaviour. I've been a fan of the direction in which I saw Joplin's development move, and been using it for such a long time – I'd hate it if I was forced to prepare for a switch to alternative notetaking apps.
This is not an issue with Joplin but with your server. Why is it denying permission to create a directory? This is something you might want to investigate - you could ask here since there many Nextcloud users, but the Nextcloud forum might be an even better place to ask about this.
That sounds like good advice, thank you.
While I wait for responses from the Nextcloud community, it may be worth noting a detail I found out today:
Contrary to my previous observation that only the default profile syncs without issue while all additional profiles fail the sync process, it is now apparent that any of the profiles syncs fine as long as it's the first active profile after a reboot. All profiles switched to from that first active profile will not sync properly.
It should also be pointed out that this problem only occurs when syncing from the Joplin client for Androi, but all profiles synchronise perfectly in the macOS-based Joplin client.
Can you give me the link to your question to the NextCloud community? I have the same problem and would like to follow the topic in the NextCloud community or participate in the dialogues if appropriate.
Of course. Here you are.
Seeing the answer, I guess we're just passing the buck to one another here. I'm pretty sure there's nothing we can fix on our side since the app simply cannot do anything if access is denied.
It looks like it's the "locks" folder that can't be created - have you tried creating it manually on Nextcloud side? Or if it exists, maybe try to delete it and create it again? This is just temporary data so it's safe to delete it
Thank you @moontan 
I had to re-activate my two-year-old Nexcloud Community Account before I could reply to you.
My first post there is my response to your topic. Since it is a complex topic, my post has become correspondingly long. The security mechanisms there now mean that this - my first - post there must first be approved by a moderator. We'll see...
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.
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.
Approval granted. Here we go:
Yes I remember checking this and I have no idea why it was doing this. But on the other hand many people use Nextcloud without any issue so Joplin does work with Nextcloud. But there must be something about this configuration that means it doesn't work.
Just a thought - could it be a reserved keyword? Maybe in this setup "locks" is reserved and so it's preventing any access to it? Probably more a question to the Nextcloud experts.
Yes - let's keep our fingers crossed that some Nextcloud experts will volunteer to help.
How many people use Nextcloud with Android and multiple Joplin profiles without having any problems? It might be good to know someone who does so, so that you can compare certain details if necessary. @laurent , haven't you even tried to reproduce this problem with one of your own Nextclouds without being able to reproduce the problem there?
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 you 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?
There's definitely something bizarre going on here. I was able to replicate a similar (although maybe not exactly the same issue).
On Android I can sync the default profile but when trying to sync a second profile with another NC account I get "WebDAV directory not found".
The desktop client has no problem syncing.
I am not sure what is going on, 2 requests from Android look exactly the same to me:
PROPFIND /remote.php/dav/files/admin/joplin/ HTTP/1.1
depth: 0
authorization: Basic <redacted>
cache-control: no-store
if-none-match: JoplinIgnore-45210
user-agent: Joplin/1.0
Content-Type: text/xml
Content-Length: 190
Host: 192.168.1.79:8087
Connection: Keep-Alive
Accept-Encoding: gzip
Cookie: cookie_test=test; oc_sessionPassphrase=<redacted>; nc_sameSiteCookielax=true; nc_sameSiteCookiestrict=true; oc2vt4y9tr8e=3ddcad8cd6ff9c7312b077958038496d
PROPFIND /remote.php/dav/files/test/joplin/ HTTP/1.1
depth: 0
authorization: Basic <redacted>
cache-control: no-store
if-none-match: JoplinIgnore-6475
user-agent: Joplin/1.0
Content-Type: text/xml
Content-Length: 190
Host: 192.168.1.79:8087
Connection: Keep-Alive
Accept-Encoding: gzip
Cookie: oc_sessionPassphrase=<redacted>; nc_sameSiteCookielax=true; nc_sameSiteCookiestrict=true; oc2vt4y9tr8e=3ddcad8cd6ff9c7312b077958038496d
curl call from desktop - also succeeds
* Trying 192.168.1.79:8087...
* Connected to 192.168.1.79 (192.168.1.79) port 8087
> PROPFIND /remote.php/dav/files/test/joplin/ HTTP/1.1
> Host: 192.168.1.79:8087
> Accept: */*
> Depth: 0
> Authorization: Basic <redacted>
> Content-Type: text/xml
> Cache-Control: no-store
> If-None-Match: JoplinIgnore-67263
> User-Agent: Joplin/1.0
> Content-Length: 190
I guess one difference I can see is the successful requests all have this cookie set cookie_test=test. No idea where this is coming from, certainly not from Joplin.
UPD
actually, I'm pretty sure it's set by Nextcloud. I can see it mentioned in its source code a few times.
UPD2
not sure how this can be coming from NC given I capture network traffic on the wire, hmm
I suspect there's some bug in how Joplin handles cookies on Android. I am seeing issues even without 2 profiles like this:
I think some cookie specific to a particular nextcloud account gets saved on step 2 and then incorrectly used for all subsequent steps for a different account.
That could be related to cookies but as I know we don't look at cookies or explicitly pass them around. Auth is just basic-auth, so it's email+password that's sent with each request (hopefully over https)
I suppose it's the underlying network library that attaches these cookies. RN fetch blob certainly does this automatically.