WebDAV mounts read only or has some permissions issues that make it seem this way

[antonlinus]

Describe the bug

when i mount a space via WebDAV as described here i can mount the space as a volume just fine, read all files but i can't upload a new file or replace/edit an old file. trying to results in either an error message abount insufficient space on the volume or in linux some permissions or input/output errors. this seems to affect macOS and Linux using the built-in clients as well as Mountain Duck on mac and davfs2 via linux cli.

Steps to reproduce

1. Check "Show WebDAV in Spaces" option in WebUI settings, create AppToken, copy WebDAV URL from space info
2. mount space via WebDAV HTTPS using mountain duck or any webdav client, provide AppToken as password
3. space should mount as a network volume and you should be able to read all folders/files in the space
4. copy a new file into any folder or edit any file or folder e.g. by renaming
5. you should get some error e.g. insufficient space available on volume

Expected behavior

space should mount as rw network volume via WebDAV and i should be able to upload files and edit existing.

Actual behavior

seemingly mounts as read only volume and volume mounts with 0 bytes available

Setup

latest docker-compose version of opencloud running inside debian trixie vm on debian trixie host behind nginx proxy. mountain duck macOS client & stock debian gnome file explorer app

Details

not sure if this is related but docker logs is full of errors like this one & not much else that seems related to webDAV issues

{"level":"error","service":"proxy","error":"gateway: grpc failed with code CODE_PERMISSION_DENIED","time":"2026-02-23T14:52:57Z","line":"github.com/opencloud-eu/opencloud/services/proxy/pkg/middleware/create_home.go:87","message":"error when calling Createhome"}

mountain duck on macOS notifies me that the connection was made but available space is 0B

[dragonchaser]

Can reproduce it with davfs2 on arch.

HOWTO reproduce

1. mount a space using davfs via cli: mount -t davfs 'https://<your.tld>/remote.php/dav/spaces/<spaceID>' /path/to/mountpoint
2. cd /path/to/mountpoint
3. touch foo.txt

Will result in touch: cannot touch 'foo.txt': Permission denied

[michaelstingl]

Reproduced on 5.0 rolling (PosixFS, external Keycloak IDP). Tested with OIDC Bearer and App Tokens — same results.

The bug is in PROPFIND quota-available-bytes for unlimited spaces. Server-side writes via PUT/MKCOL succeed — mount clients (davfs2, Mountain Duck, Finder) never attempt them because their statfs() implementation reads PROPFIND quota and the kernel blocks writes when available bytes is 0 or unknown.

PROPFIND results

Quota setting	Graph API remaining	PROPFIND quota-available-bytes
explicit (e.g. 1 GB)	1000000000	1000000000 (correct)
unlimited, never set (total absent)	9223372036854775807	-2 (unknown)
unlimited, explicitly set (total=0)	9223372036854775807	0

Same behavior for personal and project spaces. Subfolders inherit the space root value correctly. Auth method makes no difference.

The two broken values depend on whether a quota xattr was ever written:

• Never written (default personal spaces, virtual Shares space) → -2
• Written as 0 (space created with total:0, or quota set then reset to unlimited) → 0

Workaround

Setting an explicit quota makes PROPFIND return the correct value immediately:

curl -X PATCH -H "Authorization: Bearer $TOKEN" \
  'https://{domain}/graph/v1.0/drives/{drive-id}' \
  -H 'Content-Type: application/json' \
  -d '{"quota":{"total":100000000000}}'

Reproduction without mounting

curl -s -X PROPFIND -u "$USER:$APP_TOKEN" -H "Depth: 0" \
  -H "Content-Type: application/xml" \
  -d '<?xml version="1.0"?><d:propfind xmlns:d="DAV:"><d:prop><d:quota-available-bytes/></d:prop></d:propfind>' \
  "https://{domain}/remote.php/dav/spaces/{space-id}" | xmllint --format -

[michaelstingl]

Root cause

The PROPFIND handler and GetQuota/Graph API use different code paths for quota:

• GetQuota / Graph API reads the raw quota xattr, then passes it through calculateTotalUsedRemaining() which translates "0" → remaining = math.MaxUint64. This works correctly.

• PROPFIND reads the same raw xattr via readQuotaIntoOpaque() → md.Opaque["quota"] and returns it directly as quota-available-bytes. For unlimited spaces where the xattr is "0", this returns literal 0 to WebDAV clients.

RFC 4331 on unlimited quota

"If a resource has no quota enforced or unlimited storage ('infinite limits'), the server MAY choose not to return this property (404 Not Found response in Multi-Status), although this specification RECOMMENDS that servers return some appropriate value (e.g., the amount of free disk space)."

Fix idea (not tested)

The PROPFIND handler could treat "0" (unlimited) the same as absent — similar to how CheckQuota in node.go already handles it:

// propfind/propfind.go:1108
if quota = utils.ReadPlainFromOpaque(md.Opaque, "quota"); quota == "" || quota == node.QuotaUnlimited {
    quota = net.PropQuotaUnknown
}

-2 is not strictly RFC-compliant but has been used by ownCloud 10 and Nextcloud for years — clients in that ecosystem handle it gracefully.

A more complete approach would be returning actual free disk space for local/PosixFS backends, as the RFC recommends.