nextcloud/server · error · OCA\DAV\Connector\Sabre\Exception\Forbidden

No read permissions. This might be caused by files_accesscon

Error message

No read permissions. This might be caused by files_accesscontrol, check your configured rules

What it means

Directory::getChildren() refuses to list a directory whose underlying storage reports it as non-readable. When the files_accesscontrol app is enabled for anyone, the 403 message appends a hint pointing at workflow rules. Returning 403 instead of 404 is deliberate so callers know the collection itself exists.

Source

Thrown at apps/dav/lib/Connector/Sabre/Directory.php:262

	/**
	 * Returns an array with all the child nodes
	 *
	 * @return \Sabre\DAV\INode[]
	 * @throws \Sabre\DAV\Exception\Locked
	 * @throws Forbidden
	 */
	#[\Override]
	public function getChildren() {
		if (!is_null($this->dirContent)) {
			return $this->dirContent;
		}
		try {
			if (!$this->info->isReadable()) {
				// return 403 instead of 404 because a 404 would make
				// the caller believe that the collection itself does not exist
				if (Server::get(IAppManager::class)->isEnabledForAnyone('files_accesscontrol')) {
					throw new Forbidden('No read permissions. This might be caused by files_accesscontrol, check your configured rules');
				} else {
					throw new Forbidden('No read permissions');
				}
			}
			$folderContent = $this->getNode()->getDirectoryListing();
		} catch (LockedException $e) {
			throw new Locked();
		}

		$nodes = [];
		$request = Server::get(IRequest::class);
		$l10nFactory = Server::get(IFactory::class);
		$l10n = $l10nFactory->get(Application::APP_ID);
		foreach ($folderContent as $info) {
			$node = $this->getChild($info->getName(), $info, $request, $l10n);
			$nodes[] = $node;
		}
		$this->dirContent = $nodes;

View on GitHub (pinned to ecdeb153ff)

Solutions

Ask an admin to review the files_accesscontrol rules matching this path and user (workflow event log shows which rule hit).
Narrow the rule matchers or exclude the affected users, groups, or paths.
If the block is intended, teach clients to render the 403 message instead of retrying.

Defensive patterns

Strategy: try-catch

Try / catch

try {
    $children = $client->propfind($dirUrl, [], 1);
} catch (Forbidden $e) { // HTTP 403: folder exists but is not listable
    reportUnreadableFolder($dirUrl, $e->getMessage()); // message names files_accesscontrol
    // do not retry — a rule must change first
}

Prevention

Map files_accesscontrol rules to affected groups and paths before enabling them.
Surface the 403 message to users — it names the likely cause.
Admins: check the workflow event log to confirm which rule matched.

When it happens

Trigger: PROPFIND (Depth 1) or any listing on a WebDAV directory whose read access is blocked by a files_accesscontrol workflow rule matching the user, path, or file metadata.

Common situations: Compliance rules denying groups access to folders; workflow rules with overly broad matchers catching legitimate users; rule changes rolled out without checking affected paths.

Related errors

AI-assisted analysis of nextcloud/server@ecdeb153ff (2026-08-17). Data as JSON: /api/errors/43aabd95924ef5bc. Report an issue: GitHub.