Today Android version 1.0.308 began to fail to synchronize saying “unauthorized”:
PROPFIND .lock: Unknown error 2 (401): <!DOCTYPE…
Credentials are fine, I did not change anything in settings, but I remember upgrading android app at morning, nothing else was changed. Linux version 1.0.167 and terminal version 1.0.146 are still synchronizing just fine.
Then it times out with “Unauthorized” message. But according to apache’s logs basic auth 100% passed.
Android app log:
10-14T12:49:30,10,"""Error: PROPFIND .lock: Unknown error 2 (401): <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>401 Unauthorized</title>
</head><body>
<h1>Unauthorized</h1>
<p>This server could not verify that you
are authorized to access the document
requested. Either you supplied the wrong
credentials (e.g., bad password), or your
browser doesn't understand how to supply
the credentials required.</p>
<hr>
<address>Apache/2.4.41 (Unix) Server at xxx Port 80</address>
</body></html>
Code: 401
construct@[native code]
c@index.android.bundle:524:482
f@index.android.bundle:522:363
s@index.android.bundle:521:219
k@index.android.bundle:1211:5765
index.android.bundle:1211:6674
p@index.android.bundle:151:423
index.android.bundle:151:1740
p@index.android.bundle:151:423
n@index.android.bundle:151:898
index.android.bundle:151:1076
f@index.android.bundle:113:155
index.android.bundle:113:882
y@index.android.bundle:118:657
C@index.android.bundle:118:1021
callImmediates@index.android.bundle:118:3216
callImmediates@[native code]
value@index.android.bundle:28:2873
index.android.bundle:28:1264
value@index.android.bundle:28:2565
value@index.android.bundle:28:1234
value@[native code]
value@[native code]""
Where to look for permissions and why it worked fine in previous version without them? It looks like horrible bug if app needs new permissions but does not request it…
Failing also on Android version 1.0.310.
But I remember I have upgraded 4 days ago but just today this issue occurred for me.
The only difference - I’m aware of - is an update of already existing note.
I’m running docker image of apache+web_dav module and as reverse proxy + TLS terminator I’m running nginx.
What’s strange:
backend apache reports 301 for PROPFIND /.lock
nginx frontend reports 405 for PROPFIND /.lock
anyway, other resources sync continues without the issue. Just the updated note is still old version on Android.
Maybe this issue was even before but I just didn’t update notes only added new ones, don’t remember…
1.0.310 did not fix the issue. Any ideas how to debug this issue further? My wife accidentally upgraded her Joplin and now she can’t sync. I’m still using 1.0.307, it syncs with the same server just fine as well as desktop and command line versions.
MKCOL is always failing with 405 but it’s fine as it tries to create directory and fails if exist already. It works as expected.
But PROPFIND /.lock is causing all issues. PROPFIND / is working fine.
The webdav backend (in my case apache+mod_dav) sends 301 for PROPFIND /.lock that is catched by reverse proxy (nginx in my case) and sending 405 to the client.
What I don’t understand is 301 code sent by my webdav server. By webdav specification, PROPFIND should return only codes 200, 403 and 404.
Or - if multiple objects was requested - code 207 and then in XML response there are codes 200/403/404 for each particular object.
Definitely have no idea why webdav server sends 301 for PROPFIND /.lock - I have default apache+mod_dav config from downloaded docker image from hub.docker.com.
@Rado1, your server redirects .lock to .lock/, which is useless, but it does it anyway. This causes an issue in Joplin (in iOS for sure but maybe in Android) too because when a request is redirected, the underlying network stack doesn’t forward the auth headers.
You might want to try the latest version 311, which fetches .lock/ directly, to see it solves your problem:
Interesting, my setup is almost the same – basic apache+webdav server and nginx frontend for SSL in two LXD containers. My apache and webdav are almost default from alpine linux image.
Many thanks. Will try version 311 this evening.
Anyway, I will try to remove this redirection on apache level as well (to avoid any issues in the future…)