Public link share of a folder inside a Team folder (groupfolder) ignores read-only permission anonymous delete/rename/move/upload possible

3 min read Original article ↗
  • This is a bug, not a question or a configuration/webserver/proxy issue.
  • I have searched the existing issues and could not find a matching open report for this exact behaviour.

Bug description

A public link share with "Read only" permission, created on a folder located inside a Team folder (groupfolders), does not enforce the read-only restriction on the public WebDAV endpoint. Anyone holding the link can delete, rename, move and create files and upload new files, although the share is read-only.

This is not a single misconfigured share. A freshly created read-only link (created via the OCS Sharing API with permissions=1, stored as permissions=17 in oc_share, i.e. read + reshare) shows the exact same behaviour. The share permission is stored correctly but is not applied to public access for files served from a Team folder mount.

For normal user folders (outside Team folders), read-only public links behave correctly (write operations return 403).

Steps to reproduce

  1. Create a Team folder (groupfolders) with a group having full permissions (31). ACL/advanced permissions disabled.
  2. As a member, create a public link share on a subfolder inside that Team folder with permission "Read only".
  3. Query the public WebDAV endpoint for the effective permissions: 
    PROPFIND https://<host>/public.php/dav/files/<token>/   (Depth: 0, prop oc:permissions)
    → Server returns RGDNVCK (Read, Get, Delete, reName, moVe, Create, mKdir).
  4. Perform a destructive operation through the link:
    • DELETE https://<host>/public.php/dav/files/<token>/<existing-file> → HTTP 204 (file is actually deleted / moved to Team-folder trash).
    • PUT https://<host>/public.php/dav/files/<token>/anyfile.txt → HTTP 201 (anonymous upload succeeds).
  5. Check oc_share: the link's permissions is 17 (read + reshare, i.e. read-only) — yet the write/delete succeeded.

Expected behaviour

A read-only public link on a folder inside a Team folder must reject write operations (DELETE/PUT/MOVE/MKCOL/rename) with 403, exactly like read-only public links on regular user folders. The oc:permissions reported for the public mount should reflect the share permission (read-only), not the underlying Team-folder storage permission.

Actual behaviour

The public mount inherits the full storage permissions of the Team folder (31) instead of the share permission. Read-only is silently ignored → anonymous delete/rename/move/create/upload.

Additional context

  • Setting the share's DB permissions to 1 had no effect — write operations still succeed, confirming the share permission is not consulted for the public Team-folder mount.
  • Reproduced after redis FLUSHALL, php-fpm restart and occ files:scan — not a caching artefact.
  • Side effect: an anonymously uploaded file ends up with filecache permissions=17 (no DELETE bit), so even server admins cannot remove it via the web UI afterwards; it can only be removed via occ files:delete. This compounds the impact.

Nextcloud version

32.0.11

groupfolders (Team folders) version

20.1.14 (latest available for the Nextcloud 32 branch; occ reports it as up-to-date)

Installation method / environment

  • PHP 8.3.31
  • Database: MariaDB
  • Caching: APCu (local) + Redis (distributed)
  • Web server: nginx