Joplin Desktop 3.7.21 – WebDAV attachments return HTTP 404 although resources exist on the se

[herbinc22]

Operating system

Windows

Joplin version

3.7.21

Desktop version info

Joplin 3.7.21 (prod, win32)

Appareil : win32, 11th Gen Intel(R) Core(TM) i5-11400F @ 2.60GHz
ID client : 115161d6d9184225b58b21b4f232c34c
Version de Synchro : 3
Version du profil : 54
Trousseau supporté : Oui
ID d'instance alternatif : -
Cible de synchronisation : WebDAV
Éditeur : Markdown

Révision : e41516e

ABC Sheet Music Plugin: 1.0.5
Backup: 1.5.1
Freehand Drawing: 4.3.0

Sync target

WebDAV

Editor

Markdown Editor

What issue do you have?

Joplin Desktop – WebDAV attachments exist on the server but cannot be retrieved on Windows

Summary

I am experiencing a reproducible problem with Joplin Desktop on Windows when using WebDAV synchronization with Infomaniak kDrive.

The main symptom is that my Markdown notes synchronize correctly, but some or all of the attachments/resources (especially images) cannot be displayed on Joplin Desktop.

The important point is that the resources do exist on the WebDAV server and have a normal file size. For example, I have verified images of approximately 2.9 MB, several MB, and other non-zero sizes directly on Infomaniak kDrive.

However, Joplin Desktop attempts to load these resources and receives:

HTTP 404 – Not Found

The browser/network developer tools also show that the failed request transfers:

0.0 kB

The same problem occurs on two different Windows computers, including a desktop PC and a laptop.

---

Environment

Joplin Desktop

• Joplin version: 3.7.21
• Platform: Windows / win32
• Processor on the tested desktop PC: 11th Gen Intel(R) Core(TM) i5-11400F @ 2.60GHz
• Synchronization target: WebDAV
• Synchronization version: 3
• Profile version: 54
• Editor: Markdown
• Keychain support: Yes
• Alternate instance ID: -
• Revision: e41516e
• Backup plugin: 1.5.1
• Freehand Drawing plugin: 4.3.0

WebDAV provider

Infomaniak kDrive

---

Android devices work correctly

I have several devices using the same Joplin synchronization target.

On my Android phone and tablet, attachments work correctly.

The notes synchronize normally and their images/attachments can be displayed.

This is an important comparison because it suggests that the resources stored on the WebDAV server are not universally inaccessible.

The problem appears specifically with the Joplin Desktop clients on Windows.

---

The problem occurs on two Windows computers

I have reproduced the same behavior on:

1. My Windows desktop PC
2. My Windows laptop

Both computers have the same general problem:

• Markdown notes synchronize.
• The note content is present.
• Resource links are present.
• Attachment/resource IDs are present.
• Some attachments do not appear.
• Images show as broken/missing.
• The local resource may appear to have a size of 0 bytes.
• Joplin attempts to request the resource.
• The request returns HTTP 404 Not Found.

This makes me think that the problem is not simply related to one corrupted Windows installation.

---

Verification directly on Infomaniak kDrive

I manually inspected the resources on my Infomaniak kDrive WebDAV storage.

This was very important because I initially suspected that the attachments might simply be missing from the server.

However, this is not what I found.

The resources are actually present on kDrive.

Several files have normal sizes, for example:

• hundreds of KB;
• around 1–3 MB;
• several MB.

I specifically checked an image that Joplin Desktop could not display.

The image exists on kDrive and has a size of approximately:

2.9 MB

I can open the image directly through kDrive and see the actual image.

Therefore, the original resource does not appear to be empty or missing from the server.

---

Local Joplin resources can appear as 0 bytes

On Windows, I inspected the Joplin Desktop resources directory.

I found numerous resource files with generated/hash-like names.

Some of the files appear to have a size of:

0 bytes

This is interesting because the corresponding resources on kDrive can have a normal size.

For example, a resource can effectively have this situation:

Infomaniak kDrive:
Resource exists
Size: approximately 2.9 MB
Status: accessible

Joplin Desktop:
Resource referenced by the note
Local resource: 0 bytes / unavailable
Result: image not displayed

This seems to indicate that Joplin Desktop knows about the resource but is failing to retrieve or materialize the actual resource locally.

---

The Markdown reference exists

The Markdown note contains a resource reference similar to:

![Image name](:/RESOURCE_ID)

The resource ID is therefore present in the note.

Joplin knows which resource the note is referring to.

However, when the application tries to display the image, the image does not load.

Instead, I see a broken image/missing attachment.

---

HTTP 404 observed in Joplin Developer Tools

I also inspected Joplin's Developer Tools.

In the Network tab, I can see requests being made for the resource.

The requests fail with:

Status: 404

The request type is shown as:

text/plain

and the transferred size is:

0.0 kB

There are multiple failed requests for the same resource.

This is particularly useful because it gives a concrete technical symptom rather than simply saying that the image does not appear.

In other words, Joplin Desktop is attempting to retrieve the attachment, but the requested resource is apparently not found at the location being requested.

---

Important observation: the server still contains the resource

This is the part I would especially like the developers to investigate.

The situation appears to be:

                 Joplin Desktop
                       │
                       │ requests resource
                       ▼
                 WebDAV / kDrive
                       │
              Resource actually exists
                       │
                       ▼
                HTTP 404 returned

The resource is visible and accessible through kDrive itself.

But Joplin Desktop receives a 404 when trying to retrieve it.

This makes me wonder whether Joplin Desktop is constructing the WebDAV resource path incorrectly, using an outdated resource location, or otherwise failing to resolve the resource ID correctly.

I do not know whether this is actually the cause, but the behavior seems consistent with a resource-resolution problem.

---

Test with a completely new Joplin profile

To rule out corruption of my existing Joplin profile, I performed another test.

I created a new Joplin test profile.

I configured the profile with the same WebDAV synchronization information for Infomaniak.

I then:

1. Created a new notebook.
2. Created a new note.
3. Added a new image attachment.
4. Synchronized the profile.
5. Checked the resource on kDrive.
6. Checked the resource from Joplin Desktop.

The image was successfully uploaded to kDrive and the corresponding file had a normal, non-zero size.

However, the image still failed to display correctly in Joplin Desktop.

Therefore, the problem does not appear to be limited to my original profile.

This is an important result because it makes an old-profile corruption issue much less likely.

---

Existing profile vs. new profile

The behavior is essentially reproducible in both cases.

Existing profile

• Notes synchronize.
• Resource references exist.
• Some local resources are 0 bytes.
• Attachments fail to display.
• Developer Tools show HTTP 404.

New test profile

• New note created.
• New image attached.
• Image uploaded to kDrive.
• Resource exists on kDrive with a normal size.
• Image still fails to display correctly on the Desktop client.

This suggests that the problem may occur during the resource retrieval process itself, rather than being caused solely by old database data.

---

Synchronization conflicts

I have also previously observed synchronization warnings such as:

"Some items cannot be synchronized."

There were also resource-related entries in the synchronization logs.

This makes me wonder whether there could be a relationship between:

• resource synchronization;
• synchronization conflicts;
• WebDAV resource IDs;
• local resource creation;
• resource downloads;
• and the HTTP 404 errors.

I would like to know whether the developers can determine if these events are related.

---

Number of resources

I also inspected the Joplin resources directory.

At one point, I found approximately 34 resource files there.

I did not manually manipulate or delete them.

This suggests that Joplin is aware of a substantial number of resources.

However, the presence of resource files locally does not necessarily mean that their contents have been successfully synchronized.

Some local files appear to have zero bytes even though corresponding resources on kDrive have a normal size.

---

Important comparison with Android

The same WebDAV account is used with my Android devices.

On Android:

Attachments work correctly.

On Windows Desktop:

Attachments fail to load.

This difference is particularly interesting.

The same WebDAV storage contains the resources.

Therefore, I would like to know whether there is a difference between the Android and Desktop implementations when resolving or downloading WebDAV resources.

---

I also investigated the possibility of a performance problem

I considered whether the issue might be caused by insufficient computer performance.

I checked the computer and also ran a McAfee performance analysis.

McAfee reported a number of general performance items, including:

• unnecessary files;
• registry-related items;
• limited available memory.

However, I do not believe these explain the Joplin problem.

The reason is that:

1. The problem occurs on two different Windows computers.
2. The Markdown notes synchronize successfully.
3. The WebDAV server contains the attachments.
4. Android can access the attachments.
5. The Joplin Developer Tools specifically report HTTP 404.
6. The failed network requests transfer 0.0 kB.
7. The same behavior can be reproduced with a new Joplin profile.

Therefore, I suspect that this is more likely to be a Joplin resource/WebDAV handling problem than a general computer performance problem.

---

My current hypothesis

I do not want to claim that I have identified the exact cause.

However, based on the tests above, my current hypothesis is that the problem may occur somewhere in the following chain:

Joplin note
     ↓
Resource ID
     ↓
Joplin Desktop resource resolver
     ↓
WebDAV request
     ↓
Infomaniak kDrive
     ↓
Existing resource
     ↓
Unexpected HTTP 404
     ↓
Resource cannot be downloaded
     ↓
Image remains unavailable

The key question is:

Why does Joplin Desktop receive HTTP 404 for a resource that is demonstrably present on the WebDAV server?

---

Questions for the Joplin developers

Could you please help me determine:

1. Resource path

Is Joplin Desktop constructing the correct WebDAV path when requesting an attachment?

2. Resource ID

Could the resource ID stored in the Markdown/database be different from the resource path being requested?

3. HTTP 404

Why would the Desktop client receive HTTP 404 when the same resource exists and can be opened through kDrive?

4. Zero-byte resources

Could the 0-byte local resource files be a consequence of a failed WebDAV download?

5. Synchronization conflicts

Could the previous synchronization conflicts have caused incorrect or incomplete resource metadata?

6. Desktop vs Android

Is there a known difference between the Android and Desktop WebDAV resource synchronization implementations?

7. Version 3.7.x

Could this be related to a regression in the Joplin 3.7.x series?

8. WebDAV compatibility

Could there be a compatibility problem between the Joplin Desktop WebDAV implementation and Infomaniak kDrive?

---

Evidence available

I can provide additional evidence if required, including:

• Joplin synchronization logs;
• screenshots of the WebDAV resources on kDrive;
• screenshots showing the correct file sizes;
• screenshots of the Joplin Developer Tools;
• Network tab showing HTTP 404;
• Console output;
• screenshots of the missing attachments;
• information about the affected resource IDs;
• information from the new test profile.

I can also provide a complete synchronization log if that would help identify the exact failure.

---

Expected behavior

When a note contains a resource such as:

![Image](:/resource-id)

and the corresponding resource exists on the WebDAV server, Joplin Desktop should:

1. locate the resource;
2. download it;
3. store it locally;
4. display it in the note.

---

Actual behavior

Instead:

1. The Markdown note synchronizes.
2. The resource reference is present.
3. The resource exists on Infomaniak kDrive.
4. The resource has a normal file size on kDrive.
5. Joplin Desktop attempts to retrieve it.
6. The request returns HTTP 404.
7. The response contains 0.0 kB.
8. The local attachment may appear as 0 bytes.
9. The image is not displayed.

---

Request

Could someone from the Joplin development team help me determine whether this is a known WebDAV/resource synchronization issue?

I have tried to isolate the problem as much as possible.

Because the issue occurs on two Windows computers, can be reproduced with a new Joplin profile, while Android devices work correctly and the resources are demonstrably present on the WebDAV server, I believe there may be a specific issue in the Joplin Desktop resource retrieval/synchronization process.

Thank you very much for taking the time to investigate this.

I would be happy to provide additional logs or technical information if needed.

[mrjo118]

I saw your original thread Joplin Desktop 3.7.18 + WebDAV/kDrive: Resources Are Created Locally but Remain 0 Bytes and Images C - #3 by mrjo118 and replied to it. At the time I also tried using a kDrive Solo trial account with Joplin 3.7.18 and was unable to reproduce the issue using a new account.

Any reason why you didn't reply to my post on the original thread?

@mrjo118

Can you share a section from the log file with the error, including some of the surrounding lines as well?

Also, do you have the Joplin data at the root on kDrive or in a sub folder? If the latter, what is the full path?

[herbinc22]

Thank you for following up and for continuing to investigate this issue.

Yes, I can provide both pieces of information.

1. Joplin log and HTTP 404 error

I will provide the relevant section of the Joplin log showing the error that occurs when Joplin Desktop tries to load the attachment.

I can also reproduce the problem with a new test profile using a clean Joplin configuration and the same WebDAV settings. I created a test notebook and added a new image attachment.

The result is the same: the Markdown note contains the attachment reference, but the image is not displayed.

In the browser DevTools, the attachment request returns:

HTTP 404 – Not Found

The request appears to be made by Joplin's attachment rendering process.

This is particularly interesting because the corresponding resource does exist on the kDrive WebDAV server.

For example, one of the image resources exists on kDrive and has a normal file size of approximately 2.9 MB. It is not a zero-byte file on the server.

However, Joplin Desktop 3.7.21 still receives HTTP 404 when trying to retrieve the resource.

2. kDrive / WebDAV folder structure

My Joplin WebDAV data is organized approximately like this:

kDrive
└── application
    └── palais mental 2.0
        ├── Joplin .md files
        └── .resource
            ├── attachment/image 1
            ├── attachment/image 2
            ├── attachment/image 3
            └── ...

The important part is that the .md note contains the attachment reference, and the corresponding resource is present in the .resource directory.

For example:

application/palais mental 2.0/
└── .resource/
    └── [attachment resource ID]

The resource exists on kDrive and has a non-zero size, but Joplin Desktop cannot retrieve it and returns HTTP 404.

3. Additional observation

I also checked several resources directly in kDrive.

Most of the resources have normal file sizes such as several hundred KB or a few MB. They are not generally zero-byte files.

This makes me think that the problem may not simply be that the attachment was never uploaded.

The situation appears to be more like:

Joplin note
     ↓
Attachment reference exists
     ↓
Joplin requests the resource through WebDAV
     ↓
kDrive contains the resource
     ↓
Joplin receives HTTP 404
     ↓
Attachment cannot be displayed

I would therefore like to determine whether Joplin Desktop is constructing the wrong WebDAV resource path, or whether there is another issue in the WebDAV synchronization/attachment retrieval process.

I can provide the relevant log excerpt so that you can compare the resource requested by Joplin with its actual location on kDrive.

I am using:

• Joplin Desktop: 3.7.21

• Platform: Windows / Win32

• Synchronization target: WebDAV

• WebDAV provider: Infomaniak kDrive

• Sync version: 3

• Profile version: 54

I will not include my WebDAV password, application password, username, or any other credentials.

Thank you again for looking into this. I would be happy to provide additional diagnostic information if needed.

deletion_log_20261004.txt (7.5 KB)

[mrjo118]

Regarding the log, I need to see the relevant section which includes the error message relating to the 404 and the surrounding log lines. This is from the main log.txt. The deletion log does not contain anything useful.

FYI I tried creating a directory structure like your on kDrive and syncing to that, and I was still unable to reproduce the issue.

[herbinc22]

Hello,

Thank you for your help.

I am attaching the log.txt file you requested so that you can analyze exactly what is happening with Joplin.

Here is the problem I am experiencing:

• I am using Joplin Desktop 3.7.21 on Windows.

• My synchronization uses WebDAV with Infomaniak kDrive.

• Markdown notes synchronize correctly.

• The attachment references are present in the notes.

• The affected files do exist on kDrive, and some have a normal file size, for example around 2.9 MB.

• However, some images/attachments are not displayed in Joplin Desktop.

• In the developer tools, the request to retrieve the attachment returns HTTP 404 – Not Found, with 0 bytes received.

• I also tested with a new Joplin profile, using a new WebDAV configuration and a new image, and the problem also occurred there.

• Therefore, the problem does not appear to be limited to my old Joplin profile.

• This WebDAV configuration worked previously, especially during July and August 2026, and the problem became noticeable in September 2026.

I also checked that the resources actually exist on kDrive.

I am therefore providing the log.txt file so that you can investigate the errors and determine why Joplin Desktop returns a 404 when retrieving a WebDAV resource that actually exists on kDrive.

Could you please check the log and let me know what exactly is causing this error and where the problem is located (Joplin Desktop, WebDAV, kDrive, or something else)?

Thank you very much for your help and for looking into this issue.

log.txt (2.1 MB)

[mrjo118]

This is the relevant error from the logs:

2026-09-13 13:56:33: [error] ResourceFetcher: Could not download resource: 0049e8eeb82045319ab62e13cb3e1162 TypeError [ERR_UNESCAPED_CHARACTERS]: Request path contains unescaped characters
Code: ERR_UNESCAPED_CHARACTERS
TypeError: Request path contains unescaped characters
    at new ClientRequest (node:_http_client:241:13)
    at Object.request (node:https:629:10)
    at RedirectableRequest.f1._performRequest (file:///C:/Users/herbi/AppData/Local/Programs/Joplin/resources/app.asar:1:1)
    at new RedirectableRequest (file:///C:/Users/herbi/AppData/Local/Programs/Joplin/resources/app.asar:1:1)
    at Object.request (file:///C:/Users/herbi/AppData/Local/Programs/Joplin/resources/app.asar:1:1)
    at file:///C:/Users/herbi/AppData/Local/Programs/Joplin/resources/lib/shim-init-node.ts:656:27
    at new Promise (<anonymous>)
    at fetchFn (file:///C:/Users/herbi/AppData/Local/Programs/Joplin/resources/lib/shim-init-node.ts:625:11)
    at Object.fetchWithRetry (file:///C:/Users/herbi/AppData/Local/Programs/Joplin/resources/lib/shim.ts:312:28)
    at Object.si.default.fetchBlob (file:///C:/Users/herbi/AppData/Local/Programs/Joplin/resources/lib/shim-init-node.ts:711:15)

It is indeed an issue with the path on your kDrive. Can you send the url you are supplying in the Joplin sync configuration (but redact your drive id from it)?

Either the url is not in the right format, or for some other reason it is not accepting the path with spaces, subdirectories or a period in the pathname. If that's the case even when the url is in the correct format, you could try moving the data to a simple path like /joplin on kDrive, then repoint the url in Joplin on all your devices