nextcloud/server · error · Sabre\DAV\Exception\ServiceUnavailable
filesystem not setup
Error message
filesystem not setup
What it means
Thrown by ObjectTree::getNodeForPath() (apps/dav/lib/Connector/Sabre/ObjectTree.php:67) as \Sabre\DAV\Exception\ServiceUnavailable (HTTP 503) when the tree's $this->fileView is null — i.e. the per-user filesystem view (OC\Files\View) was never attached to the DAV tree. The Sabre object tree cannot resolve any path without it, so every WebDAV request touching /remote.php/dav/files/ fails before any storage access happens.
Source
Thrown at apps/dav/lib/Connector/Sabre/ObjectTree.php:67
$this->rootNode = $rootNode;
$this->fileView = $view;
$this->mountManager = $mountManager;
}
/**
* Returns the INode object for the requested path
*
* @param string $path
* @return \Sabre\DAV\INode
* @throws InvalidPath
* @throws \Sabre\DAV\Exception\Locked
* @throws \Sabre\DAV\Exception\NotFound
* @throws \Sabre\DAV\Exception\ServiceUnavailable
*/
#[\Override]
public function getNodeForPath($path) {
if (!$this->fileView) {
throw new \Sabre\DAV\Exception\ServiceUnavailable('filesystem not setup');
}
$path = trim($path, '/');
if (isset($this->cache[$path])) {
return $this->cache[$path];
}
if ($path) {
try {
$this->fileView->verifyPath($path, basename($path));
} catch (InvalidPathException $ex) {
throw new InvalidPath($ex->getMessage());
}
}
// Is it the root node?
if (!strlen($path)) {View on GitHub (pinned to ecdeb153ff)
Solutions
- Ensure ObjectTree::init() is called with a valid OC\Files\View for the logged-in user before any DAV request is served — in standard Nextcloud this is done by apps/dav/lib/Server/SetupManager and the root collection; verify you are going through apps/dav/lib/Server.php bootstrap.
- If you have custom code instantiating the DAV server, mirror the core flow: build the user root via \OC\Files\Filesystem::getView() (or IRootFolder->getUserFolder()) and pass it to the tree.
- Check nextcloud.log for earlier errors during user/filesystem setup (e.g. failing lazy-user or setup:backends) that abort view creation before the DAV phase.
- After an upgrade, run occ upgrade and occ files:scan --all to make sure the filesystem layer is intact.
Example fix
// before (custom bootstrap) $tree = new ObjectTree(); $server->tree = $tree; // fileView is null -> 503 'filesystem not setup' // after $view = \OC\Files\Filesystem::getView(); // initialized for the current user $tree = new ObjectTree(); $tree->init($rootFolder, $view);
Defensive patterns
Strategy: validation
Validate before calling
// server-side, before serving DAV requests
$view = \OC\Files\Filesystem::getView();
if (!$view) {
throw new \RuntimeException('User filesystem not initialized - abort before DAV dispatch');
}
$tree->init($rootFolder, $view); Try / catch
try {
$node = $server->tree->getNodeForPath($path);
} catch (\Sabre\DAV\Exception\ServiceUnavailable $e) {
if (str_contains($e->getMessage(), 'filesystem not setup')) {
// bootstrap bug: fix tree init, do not retry
throw new \LogicException('DAV tree used before init()', 0, $e);
}
throw $e; // genuine storage 503 -> retryable
} Prevention
- Always bootstrap the DAV server through apps/dav/lib/Server.php, not by instantiating ObjectTree yourself.
- In tests, call ObjectTree::init() with a real or mocked view before any request.
- Fail fast at bootstrap if the user root folder cannot be obtained.
When it happens
Trigger: The DAV server was constructed and getNodeForPath() called before init($rootFolder, $view) ran — e.g. a custom entry point or unit test instantiating ObjectTree directly; or the user filesystem setup failed during request bootstrap so no view was handed to the tree.
Common situations: Developers writing custom Sabre plugins or CLI/bootstrap code that reuse the DAV server outside apps/dav/lib/Server::requestPath flow; broken or half-finished maintenance-mode setups where user mounting is skipped; upgrades where an app unsets the root node; tests that forget Server::get(IServerContainer)->getRootFolder() wiring.
Related errors
- $class: $msg
- File is not updatable: %1$s
- Requested file can currently not be accessed.
- Too many calendars created
- Calendar limit reached
AI-assisted analysis of nextcloud/server@ecdeb153ff (2026-08-17).
Data as JSON: /api/errors/af1fd6f38ce5a67f.
Report an issue: GitHub.