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

apps/dav/lib/Connector/Sabre/Directory.php の getNodeForPath() の571行目あたりから始め、祖先の getFileInfo() の結果がどのように処理されるかを追ってください。報告によると、Directory コンストラクターの前に false を返すことがあります。このパスに関連するテストを確認し、読み取り不可の祖先を対象とするテストを追加してください。リクエストでTypeError/HTTP 500が発生しなくなり、意図された「見つからない」またはアクセス許可の応答と一致する動作になれば完了です。

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:

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").