[WebDAV] Regression: zero-byte PUT returns 500 (Drive API 400) on v1.6.7, blocking Synology Hyper Backup

[elshaio]

Summary

Internxt WebDAV CLI v1.6.7 currently fails to create zero-byte files.

A WebDAV PUT with Content-Length: 0 reaches DriveFileService.createFile(), but the Internxt Drive API returns HTTP 400. The WebDAV server then exposes this as HTTP 500.

This completely blocks the creation of new Synology Hyper Backup repositories because Hyper Backup performs a zero-byte PUT for synobkpinfo.db while validating or initializing the destination.

This appears to be a regression of:

• Can not upload zero byte (empty) file #285
• PR [PB-4953]: feat/enable-empty-file-upload-support #446
• Commit 9c7aa5a292743bddd4c13b22e0ad61ed0910ab57

The same Synology Hyper Backup setup successfully initialized a new repository on July 31, 2026, using the same v1.6.7 Docker image. It began failing on August 5, 2026.

Environment

• NAS: Synology DS920+

• Architecture: x86_64

• DSM: 7.3.2-86009 Update 4

• Hyper Backup: 4.2.2-4262

• Client: Synology Hyper Backup

• WebDAV URL: https://127.0.0.1:3005

• Container image: internxt/webdav:latest

• Internxt CLI version: 1.6.7

• Image ID:

  sha256:86376b663a71468bf40d9dd41f85f068ca9733b579e472d097b9610b9afbbabe
  

• Image digest:

  internxt/webdav@sha256:0bbeb8aa397184a7ff4cb76c7e6e688a24d23b076d6de86e71d8d0e91825d43f
  

• Image creation date:

  2026-07-09T09:57:02.973036198Z
  

• Container creation date:

  2026-07-31T22:04:52.534691138Z
  

The container had:

status=running
restarts=0
oom=false

Authentication to Internxt Drive succeeds, and the server reports itself online. Credentials and account email have been omitted.

Why this blocks Synology Hyper Backup

When creating a new WebDAV destination, Hyper Backup performs this sequence:

1. PROPFIND on the destination.
2. MKCOL to create the .hbk repository directory.
3. PUT synobkpinfo.db with a zero-byte body.
4. If that succeeds, it continues creating repository metadata.
5. If it fails repeatedly, Hyper Backup deletes the newly created .hbk directory and reports that the destination cannot be used or is already in use.

The failure happens at step 3.

Example from the Internxt WebDAV log:

[PUT] /HyperBackup/NAHS_1.hbk/synobkpinfo.db - Start (0B)
[PUT] Request received for file at /HyperBackup/NAHS_1.hbk/synobkpinfo.db
[PUT] Uploading 'synobkpinfo.db' (0 B) to '/HyperBackup/NAHS_1.hbk/'
[ERROR MIDDLEWARE] [PUT - /HyperBackup/NAHS_1.hbk/synobkpinfo.db] Request failed with status code 400
Stack: Error: Request failed with status code 400
    at HttpClient.normalizeError
    at async HttpClient.post
    at async DriveFileService.createFile
    at async handle (/app/dist/webdav/handlers/PUT.handler.js:82:22)
[PUT] /HyperBackup/NAHS_1.hbk/synobkpinfo.db - 500

Hyper Backup retries this operation several times. It eventually cleans up the partial repository:

[DELETE] Request received for item at /HyperBackup/NAHS_1.hbk
[DELETE] Trashing folder
[DELETE] Folder trashed successfully
[DELETE] /HyperBackup/NAHS_1.hbk - 204

The corresponding Hyper Backup messages are:

Exception occurred while backing up data.
Backup task was suspended (suspension incomplete).
Failed to start backup task.
Scheduled backup has been skipped because Hyper Backup cannot resume/discard the task.

Adding fewer source folders does not help because the failure occurs during repository initialization, before backup data selection matters.

Minimal reproduction without Hyper Backup

The issue can be reproduced directly against the WebDAV server. The certificate is local/self-signed, hence curl -k.

1. Create an isolated test folder

DAV_TEST='https://127.0.0.1:3005/HyperBackup/__dav_probe_20260805'

curl -skS -i -X MKCOL "$DAV_TEST/"

Result:

HTTP/1.1 201 Created

2. Upload a zero-byte file

curl -skS -i -X PUT \
  -H 'Content-Type: application/octet-stream' \
  -H 'Content-Length: 0' \
  --data-binary '' \
  "$DAV_TEST/empty.bin"

Result:

HTTP/1.1 500 Internal Server Error
Content-Type: application/xml; charset=utf-8

<?xml version="1.0" encoding="utf-8" ?>
<D:error xmlns:D="DAV:">
  <D:responsedescription>
    Request failed with status code 400
  </D:responsedescription>
</D:error>

Corresponding WebDAV log:

2026-08-05T16:09:24.594Z [PUT] /HyperBackup/__dav_probe_20260805/empty.bin - Start (0B)
2026-08-05T16:09:24.955Z [PUT] Request received for file at /HyperBackup/__dav_probe_20260805/empty.bin
2026-08-05T16:09:24.963Z [PUT] Uploading 'empty.bin' (0 B)
2026-08-05T16:09:28.882Z [ERROR MIDDLEWARE] Request failed with status code 400
2026-08-05T16:09:28.883Z [PUT] /HyperBackup/__dav_probe_20260805/empty.bin - 500

3. Upload a one-byte file to the same destination

curl -skS -i -X PUT \
  -H 'Content-Type: application/octet-stream' \
  --data-binary 'x' \
  "$DAV_TEST/one-byte.bin"

Result:

HTTP/1.1 201 Created
Content-Length: 0

Corresponding log:

[PUT] Uploading 'one-byte.bin' (1 B)
[PUT] File uploaded to network
[PUT] File uploaded to Internxt Drive
[PUT] [RESPONSE-201]

4. Download the one-byte file

curl -skS -i "$DAV_TEST/one-byte.bin"

Result:

HTTP/1.1 200 OK
Content-Type: application/octet-stream
Content-length: 1

x

5. Remove the test directory

curl -skS -i -X DELETE "$DAV_TEST/"

Result:

HTTP/1.1 204 No Content

What this reproduction rules out

The controlled test demonstrates that:

• The local WebDAV server is reachable.
• TLS connectivity works.
• Internxt authentication works.
• Folder creation works.
• Non-empty file creation works.
• File download works.
• Folder deletion works.
• The problem does not depend on Hyper Backup itself.
• The failure is specifically triggered by a zero-byte file.
• The upstream HTTP 400 happens inside DriveFileService.createFile().

The WebDAV bridge should not return HTTP 500 for this request because v1.6.7 contains explicit zero-byte file support.

Evidence that it previously worked with the same image

The Hyper Backup support logs show that the original repository was completely new and was initialized on July 31, 2026.

The Docker container was created at:

2026-07-31T22:04:52.534691138Z

The Hyper Backup task was created approximately ten minutes later:

2026-07-31T17:14:46-05:00

Therefore, the original task used the same v1.6.7 container from its first initialization. There was no older Internxt image involved.

During the original task creation, Synology recorded:

2026-07-31T17:15:33-05:00 WebDAVUpload:
https://127.0.0.1:3005/Hyper%20Backup/NAHS_1.hbk/synobkpinfo.db

2026-07-31T17:15:43-05:00 WebDAVUpload:
https://127.0.0.1:3005/Hyper%20Backup/NAHS_1.hbk/Control/%40writer/v1.1.-1.0.0.none.none.cinfo

2026-07-31T17:15:54-05:00 WebDAVUpload:
https://127.0.0.1:3005/Hyper%20Backup/NAHS_1.hbk/_Syno_TaskConfig

2026-07-31T17:16:07-05:00 WebDAVDownload:
https://127.0.0.1:3005/Hyper%20Backup/NAHS_1.hbk/synobkpinfo.db

This sequence progressed successfully beyond synobkpinfo.db, and Hyper Backup subsequently uploaded approximately 236 GiB of a new initial backup.

The initial backup ran for approximately 69.5 hours and created many .bucket.2 and .index.2 objects before later becoming suspended.

The container was not recreated between the successful initialization and the later failure. It was only restarted on August 5:

created=2026-07-31T22:04:52.534691138Z
started=2026-08-05T15:44:18.998791183Z
image_id=sha256:86376b663a71468bf40d9dd41f85f068ca9733b579e472d097b9610b9afbbabe

This strongly suggests a server-side regression or a compatibility change in the Drive API rather than a Docker image change.

Additional Hyper Backup failures

Before the new-repository test, the original task also encountered repeated HTTP 500 responses while uploading objects such as:

/Hyper Backup/NAHS_1.hbk/Pool/0/2/716.index.2

It also later failed while creating or updating writer keep-alive objects:

/Hyper Backup/NAHS_1.hbk/Control/lock/lock_keep_alive.@writer_version_0.<uuid>

Hyper Backup retried these requests with exponential backoff and then suspended the task. There were 82 WebDAV HTTP 500 occurrences in the collected Hyper Backup log.

These may be separate symptoms of the same Drive API regression, although the zero-byte failure is independently reproducible.

Relevant implementation

The empty-file support added for #285 intentionally:

1. Accepts Content-Length: 0.
2. Skips the network content upload.
3. Calls DriveFileService.createFile() using:

size: 0
fileId: undefined

That exact createFile() operation is now being rejected by the Drive API with HTTP 400.

The currently published Docker image is v1.6.7 and uses:

@internxt/sdk 1.17.13

The current repository branch identifies itself as v1.6.8 and uses:

@internxt/sdk 1.19.0

However, as of August 5, 2026, Docker Hub still publishes v1.6.7 as latest.

It is possible that the Drive backend now requires behavior present in the newer SDK, but this is only a hypothesis.

Expected behavior

A zero-byte WebDAV request such as:

PUT /path/empty.bin
Content-Length: 0

should return:

HTTP/1.1 201 Created

A subsequent GET, HEAD, or PROPFIND should expose a file with a length of zero.

Synology Hyper Backup should then be able to finish destination validation and initialize synobkpinfo.db.

Actual behavior

The CLI accepts the WebDAV request but DriveFileService.createFile() receives HTTP 400 from the Internxt Drive API. The CLI maps this to HTTP 500, causing Hyper Backup to retry, suspend and delete the partially created destination.

Questions

1. Did the Drive API behavior for zero-byte entries change between July 31 and August 5, 2026?
2. Is this a regression of Can not upload zero byte (empty) file #285 / PR [PB-4953]: feat/enable-empty-file-upload-support #446?
3. Does @internxt/sdk 1.19.0 contain a required fix for the current Drive API?
4. Can an updated v1.6.8 Docker image be published so this can be tested?
5. Can the underlying Drive API response body be logged instead of only Request failed with status code 400?
6. Could a zero-byte WebDAV integration test be added to prevent this regression?
7. Is Synology Hyper Backup expected to be supported through Internxt WebDAV?

I can provide additional sanitized Hyper Backup or WebDAV logs if required. The complete Synology support archive contains private system information and will not be attached publicly.

[elshaio]

Additional confirmation using a source build from current main

I built the WebDAV container directly from the current internxt/cli main branch instead of using the published Docker Hub image.

Environment

• Internxt CLI/WebDAV: 1.6.8
• Internxt repository commit: a296b918118623d3a350ba5c5e79873f50680f5a
• Node.js: v24.19.0
• Container OS/kernel: linux 4.4.302+ (x64)
• NAS: Synology DS920+
• DSM: 7.3.2-86009 Update 4
• Hyper Backup: 4.2.2-4262

The failure remains reproducible with this source-built version.

Hyper Backup request sequence

Hyper Backup successfully performs the initial WebDAV operations:

PROPFIND /                                      -> 207
PROPFIND /HyperBackup/NAHS_1.hbk                -> 404
MKCOL /HyperBackup/NAHS_1.hbk/                  -> 201

It then tries to create its initial metadata database as a zero-byte resource:

PUT /HyperBackup/NAHS_1.hbk/synobkpinfo.db
Content-Length: 0

The WebDAV server recognizes it as a zero-byte upload but fails while creating the corresponding Internxt Drive file entry:

[PUT] /HyperBackup/NAHS_1.hbk/synobkpinfo.db - Start (0B)
[PUT] Request received for file at /HyperBackup/NAHS_1.hbk/synobkpinfo.db
[PUT] Uploading 'synobkpinfo.db' (0 B) to '/HyperBackup/NAHS_1.hbk/'

[ERROR MIDDLEWARE] [PUT - /HyperBackup/NAHS_1.hbk/synobkpinfo.db]
Request failed with status code 400

at HttpClient.normalizeError
at retryWithBackoff
at HttpClient.post
at DriveFileService.createFile
at PUTRequestHandler.handle

[PUT] /HyperBackup/NAHS_1.hbk/synobkpinfo.db - 500

Hyper Backup subsequently retries the same zero-byte PUT with increasing delays, but every attempt produces the same result: the Internxt API returns HTTP 400, and the WebDAV server exposes the failure to Hyper Backup as HTTP 500.

Independent WebDAV reproduction

The behavior can also be reproduced without Hyper Backup by sending WebDAV requests directly to the container.

Creating a collection succeeds:

MKCOL /HyperBackup/__dav_probe_20260805/
HTTP/1.1 201 Created

Uploading a zero-byte file fails:

PUT /HyperBackup/__dav_probe_20260805/empty.bin
Content-Length: 0

HTTP/1.1 500 Internal Server Error

<D:responsedescription>Request failed with status code 400</D:responsedescription>

Uploading and downloading a one-byte file succeeds:

PUT /HyperBackup/__dav_probe_20260805/one-byte.bin
Content-Length: 1

HTTP/1.1 201 Created

GET /HyperBackup/__dav_probe_20260805/one-byte.bin

HTTP/1.1 200 OK
Content-Length: 1

x

Relevant implementation detail

In the current PUTRequestHandler, content upload to the storage network is skipped when contentLength === 0. The handler then still calls DriveFileService.createFile() with a payload whose effective values include:

size: 0
fileId: undefined

The real Internxt API rejects that file-entry creation request with HTTP 400.

The existing unit test for an empty WebDAV upload mocks DriveFileService.createFile(). Therefore, it confirms the handler's intended control flow but does not verify that the real Internxt API accepts the resulting zero-byte file payload.

Conclusions

• The issue is reproducible with both the published 1.6.7 image and a source build of 1.6.8 from current main.
• Authentication succeeds.
• PROPFIND and MKCOL succeed.
• Non-empty PUT and GET operations succeed.
• Container health, DNS and basic network connectivity are not the immediate cause.
• The reproducible failure is specifically the creation of a zero-byte file entry through the Internxt Drive API.
• This blocks Synology Hyper Backup immediately because its first synobkpinfo.db upload is zero bytes.

Relation to PR #608

PR #608 (Add opt-in Synology Hyper Backup WebDAV mode) was closed without being merged.

Its zero-byte placeholder shortcut only matches numbered .bucket and .index paths under /Pool/. The first resource failing here is:

/HyperBackup/NAHS_1.hbk/synobkpinfo.db

Therefore, the zero-byte shortcut proposed in PR #608 would not cover this initial Hyper Backup failure as currently implemented.

Requested behavior

WebDAV should successfully create and represent a zero-byte resource, including when no storage-network upload and therefore no fileId exists. This needs to work for synobkpinfo.db and other legitimate empty resources, not only for selected Hyper Backup placeholder filename patterns.

[larryrider]

Hey @elshaio , thanks for the very detailed report!

I reviewed the zero-byte upload path in PUT.handler.ts / DriveFileService.createFile, and the payload the CLI sends for a size: 0 upload is correct: fileId is left undefined, which is exactly what the Drive API's validator expects for empty files. I also re-ran your repro directly against the current (production) Drive API from a local build:

• curl -X PUT -H 'Content-Length: 0' --data-binary '' https://127.0.0.1:3005/... → 201 Created
• Same request with a non-empty body → 201 Created

I couldn't reproduce the 400 today, so it looks like a transient issue on the Drive API side or an specific account related bug, rather than a persistent CLI-side regression.

That said, while investigating I found and fixed a real bug in the CLI itself: the WebDAV error-handling middleware only recognized a statusCode property on errors, but errors normalized by @internxt/sdk's HTTP client expose the real status as status and the upstream API's actual error message in data. Because of that mismatch, any error coming back from the Drive API, regardless of its real status code, was being reported to WebDAV clients as an opaque 500 with a generic "Request failed with status code XXX" message, and the real validation message was silently dropped from both the response and the logs. That's exactly why you saw a 500 with no useful detail even though the underlying failure was a 400.

I have prepared a fix for this and covered it with regression tests, so going forward the WebDAV server will return the real status code and the actual Drive API error message (in the logs and in the WebDAV error response) whenever something like this happens again, which will make it possible to tell immediately whether it's a backend validation issue, quota, auth, etc.

I would like to keep this issue open until this fix ships and you have had a chance to retest it with Hyper Backup. If it happens again, the logs should now show the real reason and we can act on it directly instead of guessing. Will update here once it's on main!

[elshaio]

Thanks for investigating this and for preparing the error-handling fix.

I repeated the test today and the zero-byte upload is unfortunately still consistently failing from my account. This retest used a locally built WebDAV container from the main checkout, reporting:

Internxt WebDAV: 1.6.8
Node.js: v24.19.0
OS: linux 4.4.302+ (x64)
Client: Synology Hyper Backup 4.2.2-4262

Authentication and the preceding WebDAV operations succeeded:

2026-08-06T17:40:10.067Z  WebDAV server listening
2026-08-06T17:40:59.459Z  PROPFIND / -> 207
2026-08-06T17:41:00.202Z  PROPFIND /HyperBackup/NAHS_1.hbk -> 404
2026-08-06T17:41:43.515Z  Folder created with UUID e04f8ae8-3e70-448e-931e-d7eeee3816c6
2026-08-06T17:41:45.060Z  MKCOL /HyperBackup/NAHS_1.hbk/ -> 201

Immediately afterward, the zero-byte synobkpinfo.db upload failed repeatedly. All timestamps below are UTC:

2026-08-06T17:41:45.348Z  PUT synobkpinfo.db (0 B)
2026-08-06T17:41:49.488Z  Drive API returned 400

2026-08-06T17:41:55.505Z  PUT synobkpinfo.db (0 B)
2026-08-06T17:42:00.435Z  Drive API returned 400

2026-08-06T17:42:07.447Z  PUT synobkpinfo.db (0 B)
2026-08-06T17:42:16.106Z  Drive API returned 400

2026-08-06T17:42:25.121Z  PUT synobkpinfo.db (0 B)
2026-08-06T17:42:28.554Z  Drive API returned 400

The corresponding error remains:

[ERROR MIDDLEWARE] [PUT - /HyperBackup/NAHS_1.hbk/synobkpinfo.db]
Request failed with status code 400

at HttpClient.normalizeError
at retryWithBackoff
at HttpClient.post
at DriveFileService.createFile
at PUTRequestHandler.handle

[PUT] /HyperBackup/NAHS_1.hbk/synobkpinfo.db - 500

This is also consistent with my earlier direct WebDAV reproduction on the same account: a zero-byte PUT failed, while a one-byte PUT and subsequent GET succeeded.

I understand from your investigation that the CLI payload is valid and that this may therefore be transient or account-specific. However, it remains reproducible for me across repeated attempts and on both the published container and the source-built 1.6.8 container.

I will be happy to rebuild from main and repeat both the direct curl reproduction and the Hyper Backup test as soon as your error-handling change lands. Hopefully the corrected status/message propagation will expose the Drive API's actual validation response. If an account identifier or additional correlation information would help you inspect the backend requests around the UTC timestamps above, I can provide it privately.

[larryrider]

hey @elshaio thanks for testing it again!

I now have a branch ready with the error-handling changes I mentioned, so you can give it a try:

PR: #657

This branch should fix the WebDAV error propagation, so instead of always returning a generic 500, it will now expose the actual status code and error message returned by the Drive API. That should help us determine whether this is an account-specific backend validation issue or something else.

If you have a chance to rebuild from that branch and rerun both the direct curl test and the Hyper Backup test, I would really appreciate it. Please let me know what the new error message says if the issue still occurs!!

[elshaio]

Thanks @larryrider — the improved error propagation exposed the actual cause.

I am using an Ultimate plan, so zero-byte files and NAS/CLI support are included in my plan.

At the time of the test, my active Drive was completely empty. However, Trash still contained a previously failed Hyper Backup repository with many zero-byte numbered .index / .bucket files.

At 2026-08-07T14:54:22Z, the zero-byte PUT returned:

HTTP/1.1 400 Bad Request

Request failed with status code 400
[You can not have more empty files]

I then permanently emptied the Internxt Trash. Without changing the CLI, container, request, or account, I repeated the same zero-byte PUT at 2026-08-07T15:07:33Z, and it returned:

HTTP/1.1 201 Created

This strongly indicates that zero-byte files inside Trash still count toward the account's empty-file limit.

This also explains why the new Hyper Backup repository could not create synobkpinfo.db: the failed repository in Trash had already exhausted the account-level empty-file allowance.

Could you please clarify:

1. What is the exact zero-byte file limit for an Ultimate account?
2. Is this limit intentionally applied to items in Trash?
3. Is the limit expected to support a full Synology Hyper Backup repository, which can create many zero-byte .index.N and .bucket.N placeholders?
4. Is a product-level fix planned, such as excluding Trash, increasing or removing the limit for Ultimate/NAS accounts, or safely handling Hyper Backup placeholders?

PR #608 attempted to avoid storing some Hyper Backup zero-byte placeholders. However, I understand the correctness concerns raised there about acknowledging a resource without actually persisting it. A server-side solution that preserves normal WebDAV PUT, HEAD, PROPFIND, and GET semantics would seem safer.

Since NAS backup is the primary reason I purchased the Ultimate plan, I need to determine whether a complete Hyper Backup repository is expected to be supported reliably or whether this account limit makes that use case unsupported.

[larryrider]

Hey @elshaio, Thanks for the detailed follow-up and for tracking this down.

Yes, this explains the behavior. Files that are in the Trash still count towards the account's empty-file limit. This is expected behavior on the backend, so this is not a CLI bug.

In your case, the previously failed Hyper Backup repository was still in the Trash and contained a large number of zero-byte files. Even though your active Drive was empty, those files were still contributing to the account-level limit. Once you permanently emptied the Trash, the exact same zero-byte PUT succeeded, which confirms that the CLI/WebDAV implementation itself was working correctly.

There is actually a WebDAV configuration specifically intended to avoid this situation with NAS backups. By default, WebDAV DELETE operations move files to the Trash, but you can configure the WebDAV server to permanently delete them instead:
internxt webdav-config --deleteFilesPermanently

This can also be configured in Docker using:
WEBDAV_DELETE_FILES_PERMANENTLY=true

With this enabled, files deleted through WebDAV are permanently removed instead of accumulating in the Trash, which helps prevent reaching the empty-file limit during NAS backup operations.

You can find this configuration documented in the Internxt CLI README under internxt webdav-config:
Internxt CLI README – WebDAV configuration

So, given the new information, I think we can consider the issue explained and resolved. The underlying behavior comes from the backend's empty-file limit and the fact that Trash items count towards it, rather than from the CLI.

I will close this issue for now as it isn't a CLI issue. Thanks again for the extremely detailed investigation and for helping us identify the actual cause. I really appreciate the time you put into reproducing and narrowing this down!