Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

[Bug]: WebDAV TypeError (HTTP 500) in Directory::getNodeForPath when an ancestor is hidden by a Team folders ACL (Directory.php:571)

Open Beginner friendly
  • Is something wrong?
#65,248 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
2/5
Estimated time
1-3 hours
Newbie friendliness
76/100
Issue type
Bug
Clarity
Clearly specified
Activity status
Active
Tech stack
php
Domain
api, backend

Research direction

Start in apps/dav/lib/Connector/Sabre/Directory.php, around getNodeForPath() line 571, and trace how ancestor getFileInfo() results are handled; the report says it can return false before the Directory constructor. Check related tests for this path and add coverage for an unreadable ancestor. Done when the request no longer produces a TypeError/HTTP 500 and the behavior matches the intended not-found or granted-access response.

Written by the indexing model from the issue text.

Description

34-feedback
Bug description

A WebDAV request for a folder whose parent is not readable to the user returns HTTP 500 (TypeError) instead of a clean response, when the parent is hidden by a Team folders (groupfolders) ACL rule.

OCA\DAV\Connector\Sabre\Directory::getNodeForPath() walks up the ancestors to check that each one is readable (added in #54441, "to keep ACL checks working in files_accesscontrol"):

// apps/dav/lib/Connector/Sabre/Directory.php, v34.0.4, lines 569-571
$info = $this->fileView->getFileInfo($scanPath, false);
$directory = new Directory($this->fileView, $info, $this->tree, $this->shareManager);
$readable = $directory->getNode()->isReadable();

For an ancestor that a groupfolders ACL makes unreadable, View::getFileInfo() returns false, not an unreadable FileInfo. The false reaches the Directory constructor unchecked, which throws:

TypeError: OCA\DAV\Connector\Sabre\Directory::__construct(): Argument #2 ($info) must be of type OCP\Files\FileInfo,
false given, called in /var/www/html/apps/dav/lib/Connector/Sabre/Directory.php on line 571
  #00 OCA\DAV\Connector\Sabre\Directory->__construct()      apps/dav/lib/Connector/Sabre/Directory.php:571
  #01 OCA\DAV\Connector\Sabre\Directory->getNodeForPath()   3rdparty/sabre/dav/lib/DAV/Tree.php:86
  #02 Sabre\DAV\Tree->getNodeForPath()                      3rdparty/sabre/dav/lib/DAV/Server.php:971
  #03 Sabre\DAV\Server->getPropertiesIteratorForPath()      3rdparty/sabre/dav/lib/DAV/Server.php:1664
  #04 Sabre\DAV\Server->writeMultiStatus()                  3rdparty/sabre/dav/lib/DAV/Server.php:1649
  #05 Sabre\DAV\Server->generateMultiStatus()               3rdparty/sabre/dav/lib/DAV/CorePlugin.php:346
  #06 Sabre\DAV\CorePlugin->httpPropFind()                  3rdparty/sabre/event/lib/WildcardEmitterTrait.php:89
  #07 Sabre\DAV\Server->emit()                              3rdparty/sabre/dav/lib/DAV/Server.php:472
  #08 Sabre\DAV\Server->invokeMethod()                      apps/dav/lib/Connector/Sabre/Server.php:215
  #09 OCA\DAV\Connector\Sabre\Server->start()               apps/dav/lib/Server.php:434
  #10 OCA\DAV\Server->exec()                                apps/dav/appinfo/v2/remote.php:25
  #11 require_once()                                        remote.php:152

Uploads fail the same way. A PUT into the folder reaches the same line through OCA\DAV\Upload\ChunkingV2Plugin->beforePut() → prepareUpload() (ChunkingV2Plugin.php:171 / 342) → Tree->getNodeForPath().

This also blocks the legitimate case

This isn't only a configuration that is "unsupported by design":

  1. The ACL engine grants the access. occ groupfolders:permissions <id> --test --user alice Restricted/alice reports +read, +write, +create, +delete, +share, and the web UI / ACL model let admins configure exactly this. Users with a valid grant get a server error instead of either their data or a clean denial. Desktop clients see a 500, not a 403/404, so they can't tell "no access" from "server broken".
  2. The same unguarded call has another trigger with no ACL involved. Groupfolders trashbin entries over WebDAV hit it too: nextcloud/groupfolders#4984 (same TypeError, same getNodeForPath chain, NC 33.0.7 / groupfolders 21.0.13, open). Any path where getFileInfo() returns false for an ancestor turns into a 500.

Whatever the intended outcome is (207 because the ACL grants read, or 404 because the parent is unreadable, as the loop's NotFound suggests), a TypeError/500 shouldn't be the answer. A minimal fix would treat $info === false like an unreadable ancestor and throw NotFound.

Steps to reproduce
  1. Nextcloud 34.0.4 with Team folders 22.0.6 (groupfolders/acl-inherit-per-user at its default false; true behaves the same).
  2. Create a team folder TF. Grant group dept (members alice, bob) all permissions. Enable advanced permissions.
  3. Create the subfolders TF/Restricted and TF/Restricted/alice.
  4. occ groupfolders:permissions <id> --group dept Restricted -- -read
  5. occ groupfolders:permissions <id> --user alice Restricted/alice -- +read +write +create +delete
  6. occ groupfolders:permissions <id> --test --user alice Restricted/alice → +read, +write, +create, +delete, +share
  7. As alice: PROPFIND /remote.php/dav/files/alice/TF/Restricted/alice with Depth: 0 (or 1) → HTTP 500, <s:exception>TypeError</s:exception>.
  8. As alice: PUT /remote.php/dav/files/alice/TF/Restricted/alice/test.txt → HTTP 500.

Variants tested, each in both acl-inherit-per-user modes:

Rule for dept on Restricted alice → Restricted/alice
-read 500
-read -write 500
-read -write -create -delete -share 500
+read -write -create -delete -share (parent readable), sibling folders denied 207 (works)

Users who can read Restricted (e.g. a group with +read on it) get 207 on Restricted/alice. Only users for whom an ancestor is unreadable hit the TypeError.

Expected behavior

No 500. Either the ACL-granted access (207), or, if readable ancestors are intentionally required, a 404 Not Found like the rest of getNodeForPath() produces.

Nextcloud Server version

34 (observed on 34.0.4)

Affected versions
  • Observed: 34.0.4 (official image nextcloud:34.0.4-apache).
  • By source inspection: the same unguarded getFileInfo() → new Directory() lines exist since #54441 in 33.0.0 and later, stable33, stable34 (identical to 34.0.4), 35.0.0, 35.0.1 and master. stable32 does not have this code path. There is no 34.0.5 yet.
Operating system / PHP / Web server / Database

Official Docker image nextcloud:34.0.4-apache: Debian, PHP 8.5.10 (mod_php), Apache 2.4.68, behind a reverse proxy. PostgreSQL 18.6.

List of activated apps (relevant)

groupfolders 22.0.6, admin_audit 1.24.0, files_versions, files_trashbin, files_sharing (defaults of the image otherwise).

Additional info

Related: nextcloud/groupfolders#4984 (same TypeError, trashbin trigger). Introduced with nextcloud/server#54441 ("Add INodeByPath to Directory").

Dominant language
PHP
Stars
37.2k
Forks
5.3k
Avg merge
2d 4h
Merged PRs (30d)
656

Getting set up

Open in Codespaces

Starts the project's dev container in your browser, under your own GitHub account.

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from nextcloud/server

All issues in nextcloud/server

Similar issues

More PHP issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.