I'm not sure what directory that is, exactly. Sure, it's called /locks, but what is the parent directory?
When I go look at my actual Nextcloud data directory on the server's filesystem, I see many /locks directories, including under the main folder of the profile I'm trying to sync and getting the error on. I've tried creating the directory when it did not exist, and when it did exist, I tried deleting it, but it never had an affect on the MKCOL error one way or another.
Since migrating, I've also seen this error:
Error: GET info.json: No public access to this resource., AppAPIAuth has not passed, Username or password was incorrect, No 'Authorization: Bearer' header found. Either the client didn't send one, or the server is mis-configured, Username or password was incorrect (Exception Sabre\DAV\Exception\NotAuthenticated) (401)
However, I think this may be related to the fact that my authentication is setup differently this time. I didn't take very good notes the first time I set up Nextcloud and Joplin, but, whatever I did, I didn't have to check the Ignore TLS certificate errors checkbox to get it to sync. Now I do, otherwise it complains about my self-signed certificate or occasionally gives this error, which goes away after a few attempts.
The parent directory is the same directory which as all the .md files for your Joplin data, which should be the directory you set as the sync path in Joplin.
Also, would you mind sharing a screenshot of the directory with all the locks directories, to see what you are referring to?
Sure, here is ls -l output for both profile directories and their locks directories (I did have to create the one on the alternate profile changelog and it still has not been populated):
I'm running out of ideas here, but have 2 other suggestions to try:
Change the webdav url in Joplin to use /webdav/ instead of /dav/ in it. If you get an error initially, try clicking sync again anyway and see if it works. This was suggested here: "Unsupported WebDAV URL format" ERROR - #8 by dpoulton
Finally, what about if you set chmod 777 on either or both of the joplin and changelog directories, and all their child files and folders recursively. A bit overkill, but worth a try
Thanks for sticking with me in the thread here mrjo118, your diligence is appreciated even though we seem to be stymied still.
I tried chmod -r 777 on both directories, still no dice.
Interestingly, when I change dav to webdav in my sync target URL, I get an error in the "Check Sync Configuration" view, then when I actually sync, it hangs for quite a few seconds, and I get a slightly different error:
MKCOL locks/: Parent node does not exist (Exception Sabre\DAV\Exception\Conflict) (409)
Which is different from what I was getting before:
MKCOL locks/: Permission denied to create directory (Exception Sabre\DAV\Exception\Forbidden) (403)
The only other error I'm seeing regularly is the GET info.json one.
I'm also a bit stumped, and pretty bummed that there doesn't seem to be a way through this yet. Maybe I should start asking on a Nextcloud forum instead, even though there is definitely something going on with Joplin since it works fine on desktop, just not mobile.
The 409 error is same as some of the links you posted at the start of the topic. One person said that waiting 15 minutes at the getting that error made it go away when syncing again (probably unlikely to help at this point, but you never know)
Also you could try several similar variations for the webdav url, which I've seen posted in different places:
I've made a post on the Nextcloud forum to see if anyone over there has ideas:
15 minutes isn't long enough--for me, it takes anywhere from 30 minutes to 2 hours, which is just not very practical.
I don't know the first thing about DAV, but I guess it must have its own concept of user permissions, because nothing I did on the Linux filesystem made any difference. But I can't find any settings in the Nextcloud admin that have to do with lock file expiry.
Thanks for the additional suggestions, I'll try each of those URL patterns and report results.
Try updating to the latest version of Joplin Android, which is now available on the Play store.
I'm not entirely sure, but potentially you may also need to uninstall the app first / clear app data for the fix to work, as the issue seems to be some authorization being remembered when it's not supposed to be.
Oh my gosh. It really is fixed! I traced the bug report back to this forum post:
It didn't show up in any of our search engine queries because the original poster just attached a screenshot of the error. Thank you so much @personalizedrefriger for the PR that fixed this issue! And thank you @mrjo118 once again for helping me to diagnose this. It turns out the fix was already in progress elsewhere, but hey, we learned about Nextcloud DAV, right?
For anyone curious, here's the entire text of the fix:
if (shim.mobilePlatform() === 'android') {
// Using credentials = 'omit' prevents authentication cookies from
// being stored. React Native has issues related to cookie authentication:
// https://github.com/facebook/react-native/issues/23185
//
// Auth tokens are passed through the "Authorization" header, so
// these cookies should not be necessary.
fetchOptions.credentials = 'omit';
}
