WebDAV reports ~4 GiB available quota for accounts with unlimited storage

Issues
1

Issue Description

For an account with no configured disk quota, WebDAV reports DAV:quota-available-bytes as though the account had a maximum quota of u32::MAX bytes.

Current main uses u32::MAX as u64 as the fallback quota when neither the account nor its tenant has a disk quota. The used quota is then subtracted from this value.

As a result, an unlimited account appears to WebDAV clients to have slightly less than 4 GiB available.

Expected Behavior

An account with unlimited storage should not be advertised as having an artificial ~4 GiB limit.

RFC 4331 §3 allows DAV:quota-available-bytes to be omitted for resources with infinite limits, or recommends returning an appropriate capacity value.

Actual Behavior

DAV:quota-available-bytes is reported as:

4294967295 - quota-used-bytes

for an account without a configured disk quota.

Reproduction Steps

  1. Create an account without a disk quota and, if applicable, without a tenant disk quota.
  2. Authenticate as that account.
  3. Send a depth-0 PROPFIND for a DAV collection requesting DAV:quota-available-bytes and DAV:quota-used-bytes.
  4. Observe that quota-available-bytes is below 4294967296, despite the account having no quota.

For example:

curl -u '[email protected]:password' \
  -X PROPFIND 'https://mail.example.com/dav/cal/user%40example.com/' \
  -H 'Depth: 0' \
  -H 'Content-Type: application/xml' \
  --data '<?xml version="1.0"?><D:propfind xmlns:D="DAV:"><D:prop><D:quota-available-bytes/><D:quota-used-bytes/></D:prop></D:propfind>'

Relevant Log Output

No error is logged. The request succeeds with 207 Multi-Status; the incorrect value is returned in DAV:quota-available-bytes.

Stalwart Version

v0.16.x

Installation Method

Built from source

Database Backend

RocksDB

Blob Storage

RocksDB

Search Engine

Internal

Directory Backend

Internal

I have reviewed the documentation and FAQ and confirm that my issue is NOT addressed there.

on

I have searched this support forum (open and closed topics) and confirm this is not a duplicate.

on

I understand that topics in this category are triaged by a bot first but a human reply will follow up. If I’d prefer a human-only reply, I’ll add the no-ai tag to my topic.

on

2

This confirms the report exactly as described: the code in crates/dav/src/common/propfind.rs (dav_quota) falls back to u32::MAX as u64 when neither the account nor its tenant has a disk quota, then computes quota.saturating_sub(used). This does produce the ~4 GiB apparent limit described. I have enough grounding to acknowledge this as a confirmed bug matching the source.

This matches what’s currently in the source: dav_quota() in crates/dav/src/common/propfind.rs falls back to u32::MAX as u64 as the “quota” whenever neither the account nor its tenant has a disk quota configured, then reports quota - used as quota-available-bytes. That does produce the behavior you describe, an unlimited account is advertised with an effective ~4 GiB ceiling instead of an actual unlimited value.

This is a genuine bug in the current WebDAV quota reporting logic rather than something documented as intended behavior, so I can’t point you to a docs page explaining it as expected. A human maintainer will need to confirm the fix (e.g. using u64::MAX or omitting the property per RFC 4331 for unlimited accounts).

This is an automated reply from the Stalwart Help Bot. Other community members may follow up if this answer is incomplete or wrong.

3

Fixed in v0.16.21 (yet to be released).