Public link share of a folder inside a Team folder (groupfolder) ignores read-only permission anonymous delete/rename/move/upload possible · Issue #4752 · nextcloud/groupfolders · GitHub

//voltron/issues_fragments/issue_layout" data-turbo-transient="true" />

Skip to content

Search or jump to...

Search code, repositories, users, issues, pull requests...

-->

Search

Clear

Search syntax tips

Provide feedback

--><br>We read every piece of feedback, and take your input very seriously.

Include my email address so I can be contacted

Cancel

Submit feedback

Saved searches

Use saved searches to filter your results more quickly

-->

Name

Query

To see all available qualifiers, see our documentation.

Cancel

Create saved search

Sign in

//voltron/issues_fragments/issue_layout;ref_cta:Sign up;ref_loc:header logged out"}"<br>Sign up

Appearance settings

Resetting focus

You signed in with another tab or window. Reload to refresh your session.<br>You signed out in another tab or window. Reload to refresh your session.<br>You switched accounts on another tab or window. Reload to refresh your session.

Dismiss alert

{{ message }}

nextcloud

groupfolders

Public

Notifications<br>You must be signed in to change notification settings

Fork<br>103

Star<br>332

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

New issue<br>Copy link

New issue<br>Copy link

Open

Open<br>Public link share of a folder inside a Team folder (groupfolder) ignores read-only permission anonymous delete/rename/move/upload possible#4752

Copy link

Labels<br>0. Needs triageIssues that need to be triagedIssues that need to be triagedbug

Description

DRKMDMZ<br>opened on Jun 9, 2026

Issue body actions

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

Create a Team folder (groupfolders) with a group having full permissions (31). ACL/advanced permissions disabled.

As a member, create a public link share on a subfolder inside that Team folder with permission "Read only" .

Query the public WebDAV endpoint for the effective permissions:<br>/public.php/dav/files// (Depth: 0, prop oc:permissions)">PROPFIND https:///public.php/dav/files// (Depth: 0, prop oc:permissions)

→ Server returns RGDNVCK (Read, Get, Delete, reName, moVe, Create, mKdir ).

Perform a destructive operation through the link:

DELETE https:///public.php/dav/files// → HTTP 204 (file is actually deleted / moved to Team-folder trash).

PUT https:///public.php/dav/files//anyfile.txt → HTTP 201 (anonymous upload succeeds).

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

Reactions are...