New install - Sync just does not work!

So, totally new joplin user looking to migrate from Evernote. IT engineer - So, yeah, I think I can handle this! 4 hours later... :frowning:

So, installed on windows. Imported a few notebook from evernote. Had installed Webdav on IIS on totally new website. Sync, and all appear to be working. Shync status shows notebooks.

Tried to setup android client. Says it is syncing and creating local files, but no notebooks ever show. Sync status shows no notebooks. After some hours, given up and try to install windows client on another win machine. Conenct that to sync source, but same. Says it is downloading all the notes, and appears to, but sync status shows no notebooks and notebook list is empty. Not errors in GUI.

I note a lot this this in the win client log

"03: Synchronizer: "Remote has been deleted between now and the delta() call? In that case it will be handled during the next sync: 6f15247dfb574ed1b186ed16be3a7320.md""

No idea if those are relevant.

Those files are there and accessible on the webdav host. Also, I have downloaded a third-party webdav client and accessed the files directly using the same credentials etc on the client machines. All OK, including downloading the files Joplin client says it is not able to download.

So, all in all, I have not idea why WebDav/IIS sync does not work. No errors in clients reported. In fact, you can see it download 100's of notes, but no notebooks show in either android or windows clients (other than the first client I setup), and those sync statuses show zero notebooks.

Have installed, deleted, re-installed, tried the sync option to delete all local content and download again (which it does), but, nada on the 2 new clients.

So, has anyone got any tips!?

1 Like

Sounds like you need to wait for a full sync. It's downloading notes, and will eventually download the notebook too

1 Like

I don;t think it's that. Very small set of data so far, and it's been hours.

Still trying to debug.

So, one of the files in the IIS file system is this. It IS accessible and downloadable via webdap as I can test this outside of Joplin. Interestingly, the joplin requests are failing, the webdav client ones (cyberduck) are not

Here is a joplin request for this file
2023-08-26 10:26:31 192.168.2.43 GET /35718d4d0c384562be081d9f0923e59d.md - 443 xxxx192.168.2.24 Joplin/1.0 - 404 3 50 1

and here is a cyberduck one

2023-08-26 10:29:47 192.168.2.43 GET /35718d4d0c384562be081d9f0923e59d.md - 443 xxxx192.168.2.100 Cyberduck/8.6.3.40040+(Windows+10/10.0.22621.0)+(amd64) - 200 0 0 0

So, the exact same GET request (as far as I can see), only, Joplin fails. Cyberduck works.

The only thing of note I see is that Cyberduck issues a PROPFIND request for that file before it downloads it, whilst Joplin just issues a bunch of GET requests for the files. The only other difference is the user agent.

Unless there are some non-printable chars in there, I do not see any file name differences, nor any reason for the failure on the joplin requests.

So, here is another test. 2 requests for the same document from the same client. One from Cyberduck, one from Joplin (after I told it to delete the local content and re-download from sync server)

Cyberduck

2023-08-26 10:51:15 192.168.2.43 HEAD / - 443 username 192.168.2.24 Cyberduck/8.6.3.40040+(Windows+10/10.0.19045.0)+(amd64) - 403 14 0 6
2023-08-26 10:51:15 192.168.2.43 PROPFIND / - 443 username 192.168.2.24 Cyberduck/8.6.3.40040+(Windows+10/10.0.19045.0)+(amd64) - 207 0 0 116
2023-08-26 10:51:15 192.168.2.43 PROPFIND /35718d4d0c384562be081d9f0923e59d.md - 443 username 192.168.2.24 Cyberduck/8.6.3.40040+(Windows+10/10.0.19045.0)+(amd64) - 207 0 0 51
2023-08-26 10:51:15 192.168.2.43 GET /35718d4d0c384562be081d9f0923e59d.md - 443 username 192.168.2.24 Cyberduck/8.6.3.40040+(Windows+10/10.0.19045.0)+(amd64) - 200 0 0 3

download it fine

Jopin

2023-08-26 10:52:49 192.168.2.43 GET /35718d4d0c384562be081d9f0923e59d.md - 443 username 192.168.2.24 Joplin/1.0 - 404 3 50 18

note, the 404.

OK, I figure it out!!!

As joplin only does the GET request on it's own, you need to add a MIME type in IIS for .md files. I added it with the type 'application/octet-stream', and, the client, after delete and re-sync, downloaded all the notebooks!

So, a little feedback. Perhaps this could be added to the docs somewhere so other people can find it. .MD does not appear to be a 'known'/standard file type extension.

2, the client is completely silent in regards to this error! If it at least reported '404', we'd have had a better idea of what was going on...

I really do hope this helps someone else as it has taken me 6 hours now to figure it out!

I would like to add, another tweak required for IIS to work I just found

I was getting PUT request errors when trying to sync y imported data.

You need to change the uploadReadAheadSize in IIS, per this

and this

image

After that, recycle your app pool and I could sync the larger notes...

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.