The Basics
- Nextcloud Server version (e.g., 29.x.x): 34.0.3.2 (first seen on 34.0.1.2, persists after upgrading)
- Operating system and version (e.g., Ubuntu 24.04): Ubuntu (AWS EC2, Bitnami stack, migrated from a Bitnami Lightsail LAMP instance via AMI export/import)
- Web server and version (e.g, Apache 2.4.25): Apache 2.4.63
- Reverse proxy and version (e.g. nginx 1.27.2): None
- PHP version (e.g, 8.3): PHP 8.x (Bitnami stack)
- Is this the first time you’ve seen this error? (Yes / No): Yes
- When did this problem seem to first start? After migrating the instance from Lightsail to EC2 and setting up Team Folders (groupfolders)
- Installation method (e.g. AIO, NCP, Bare Metal/Archive, etc.): Bitnami package originally, later a fresh manual install from the official zip (Bare Metal/Archive) on the same server
- Are you using Cloudflare, mod_security, or similar? (Yes / No): No
Summary of the issue you are facing:
The Files app throws an error whenever it needs to render a view, showing:
Error: The root must be relative to the service. e.g /files/emma
It started when I set up a Team Folder (groupfolders app) and first only affected the “Recent” and “Tags” views. Disabling groupfolders did not fix it. I then performed a completely fresh install of Nextcloud 34.0.3 (official zip, brand new empty database) on the same server, without installing groupfolders at all, and the error still appears — now even in the main Files list, for a brand new user with nothing shared and no external storage configured.
My instance is served from a subpath (https://mydomain.com/nextcloud), not the domain root, in case that’s relevant.
Steps to replicate it (hint: details matter!):
- Fresh install of Nextcloud 34.0.3 from the official zip, new MySQL database, on a Bitnami/Apache/Ubuntu EC2 instance.
- Log in as a newly created user (no shares, no external storage, no groupfolders installed).
- Navigate to Files > All files, or Files > Recent
- The view fails to load and the console shows the error above.
Log entries
Nextcloud
No corresponding entry appears in nextcloud.log at the time the error occurs in the browser — the error seems to be thrown client-side before/without a server-side exception being logged.
Web Browser
[ERROR] files: Error while fetching content
{app: "files", uid: "<user>", level: 2, error: Error: The root must be relative to the service. e.g /files/emma
at c (dist/core-common.js:1:2764103)
at new m (dist/core-common.js:1:2765890)
at new h (dist/core-common.js:1:2769110)
at y (dist/files-init.js:1:83271)
at dist/files-init.js:1:45930
at Array.map (<anonymous>)
at k.Mn (dist/files-init.js:1:45862)
at async o.fetchContent (dist/files-main.js:1:128304)}
Web server / Reverse Proxy
No relevant errors in Apache’s error_log at the time this specific error occurs.
Configuration
Nextcloud
'trusted_domains' => array (0 => 'mydomain.com'),
'overwrite.cli.url' => 'https://mydomain.com/nextcloud',
'datadirectory' => '/opt/bitnami/apache/nextcloud/data',
'dbtype' => 'mysql',
Apps
On the migrated instance (where the bug was first seen), groupfolders: 22.0.6 was installed and has since been disabled — no change to the bug. On the fresh install (where the bug also reproduces), no groupfolders/external_storage apps are installed at all.
Additional context
- I originally suspected
groupfolders(Team Folders) as the root cause, since I first noticed the error after creating one and it’s tagged withexternal_storage/groupfolders-apphere. However, since the bug reproduces on a brand-new install without groupfolders, I don’t think that app is the actual cause — possibly just what first triggered the code path that hits this bug (aggregating mount roots for a view). - Along the way I also ran into unrelated file-permission issues (
config/datadirectories not writable, “File sequence directory exists but is not writable” underphp/tmp) caused by inconsistent Unix ownership between the user runningocc/PHP-FPM and the user owningconfig.php. Fixed by aligning group ownership — mentioning in case it’s relevant to how the environment was set up, though it seems unrelated to the “root must be relative” bug itself. - Ran
occ maintenance:repair(including its “Fix invalid Team folders mountpoints” step) andocc files:scan --all— no change. - Upgraded core from 34.0.1.2 to 34.0.3.2 via
occ upgrade— no change.
Happy to provide any additional occ output or logs needed.
