TRY THIS FIRST:
On the problem computer, go to this web address and see if there's a response. I get a 404 error which means that Dropbox responded to my query. We want to know if Dropbox is responding to queries.
You don't need to get a useful webpage — it's an API endpoint. We're mainly interested in whether the browser connects immediately or sits there for 20–30 seconds before reporting a connection failure.
https://content.dropboxapi.com/
There is another thing that we can try if you're up for it? If you create a new profile in Joplin you can select a different subdirectory so you don't interfere or cause any problems with your existing data. Using the Dropbox synchronization module in Joplin that you are using now you have no choice regarding what directory the data synchronizes to. That's why we will be using file system synchronization instead. All you need to do is make a duplicate of the data in your existing directory which should be /Apps/Joplin.
Install an app called Rclone. There is a Linux installation script on their download page. Do not install from a repository it will be outdated. It can mount your Dropbox account so you can do a file system style access and synchronization to the new profile directory. We want to know if the problem is a network connectivity problem or is it a software issue. This option takes the Joplin to DropBox connection out of the equation. If you can synchronize properly using Rclone .
I can help you configuring rclone to talk to Dropbox. I am a support person for them as well.
Essentially, what you'll be doing is using Rclone to talk to DropBox rather than using Joplin to talk to Dropbox. The data should be identical.
This log narrows it down considerably. The actual Joplin/Dropbox sync failure is a network timeout while Joplin is trying to download something from Dropbox.
The important part is:
request to https://content.dropboxapi.com/2/files/download failed
Code: ETIMEDOUT
request to https://content.dropboxapi.com/2/files/download failed
Code: ETIMEDOUT
Joplin starts synchronization at 10:59:48 and the request fails at 11:00:10, about 22 seconds later. So this isn't an authentication error, Dropbox permission error, or obvious Joplin database error. Joplin made a Dropbox download request and the network connection timed out.
There's also a second, probably unrelated problem earlier:
RepositoryApi: findWorkingMirror: Using:
https://ghproxy.com/https://raw.githubusercontent.com/joplin/plugins/master
PluginState: [error] Error: Could not parse JSON:
Unexpected token '<', "<!DOCTYPE "... is not valid JSON
RepositoryApi: findWorkingMirror: Using:
https://ghproxy.com/https://raw.githubusercontent.com/joplin/plugins/master
PluginState: [error] Error: Could not parse JSON:
Unexpected token '<', "<!DOCTYPE "... is not valid JSON
That's Joplin trying to retrieve its plugin repository information through ghproxy.com. It expected JSON but received an HTML webpage instead. That isn't what caused the Dropbox synchronization to fail.
What is interesting is that two separate Internet operations are failing or behaving incorrectly during the same session:
- Joplin → plugin repository: receives unexpected HTML.
- Joplin → Dropbox content server: connection times out.
That makes me more suspicious of something affecting this computer's/network's Internet traffic than of Dropbox itself. Possibilities include VPN software, DNS filtering, proxy settings, antivirus HTTPS scanning, firewall/security software, Pi-hole/AdGuard-type filtering, or simply a network connectivity problem.
One other thing I'd like to see is a little more of the Joplin log before this section, particularly the synchronization activity preceding the Dropbox download request. That may reveal the resource ID or filename Joplin was attempting to download. If the timeout happens every single time on the same resource, then we should investigate that particular attachment rather than the network generally.