Public sharing of a Collectives subpage can make its filecache entry disappear while Readme.md remains on disk

Describe the bug

We are experiencing an intermittent but serious issue with Collectives pages.

When a user creates a public link for a Collectives page/subpage, the page can later become inaccessible in the Collectives frontend with an error such as:

Could not fetch page

and in the Nextcloud log:

Collectives NotFound error: File not found: <file_id>

We investigated this extensively and found that the actual Markdown file is NOT deleted from the filesystem.

Instead, the corresponding entry in oc_filecache disappears, while oc_collectives_pages still references the old file_id.

This leaves Collectives with a valid page database entry pointing to a file ID that Nextcloud can no longer resolve.

The exact trigger is not yet clear, but we have observed this multiple times for one user and reproduced the broken database/filesystem state with a dedicated test Collective.

Environment

• Nextcloud Server: 34.0.1
• Collectives: 4.5.0
• Database: PostgreSQL 16
• Nextcloud running in Kubernetes
• Affected user client OS: Zorin OS / Linux
• Browser: Chromium-based
• The user also accesses Nextcloud via WebDAV through GNOME Online Accounts / GNOME Files

Example / reproduction

We created a test Collective:

TestKollektive

and a page:

Testseite

Initially the page existed as:

appdata_oceffild2j99/collectives/18/Testseite.md

After creating a public link for the page, Collectives transformed it into a directory:

appdata_oceffild2j99/collectives/18/Testseite/Readme.md

The public share pointed to the directory.

At that point the database state was valid:

• Collectives page ID: 168
• file_id: 104610
• directory file_id: 104615
• public share ID: 27974

oc_collectives_pages:

id  | file_id | last_user_id | slug
----+---------+--------------+----------
168 | 104610  | andre.eberle | Testseite

Initially oc_filecache contained:

fileid | path
-------+----------------------------------------------------------
104610 | appdata_oceffild2j99/collectives/18/Testseite/Readme.md
104615 | appdata_oceffild2j99/collectives/18/Testseite

The public share referenced the directory:

share_id:    27974
share_type:  3
item_type:   folder
file_source: 104615
file_target: /Freigaben/Testseite

Broken state

Later the page became inaccessible in Collectives.

oc_collectives_pages still contained:

page_id | file_id | slug
--------+---------+----------
168     | 104610  | Testseite

But joining against oc_filecache returned:

page_id | file_id | slug      | cached_fileid | path | parent | size
--------+---------+-----------+---------------+------+--------+-----
168     | 104610  | Testseite | NULL          | NULL | NULL   | NULL

A direct query confirmed that file ID 104610 no longer existed in oc_filecache.

There was also no replacement entry for the same path.

Important: The physical file still exists

The actual file was still present on the filesystem:

/var/www/html/data/appdata_oceffild2j99/collectives/18/Testseite/Readme.md

Filesystem check:

drwxr-xr-x ... Testseite
-rw-r--r-- ... Testseite/Readme.md

Therefore this is not an actual deletion of the Markdown file.

It appears to be a desynchronization between:

• Collectives page metadata (oc_collectives_pages)
• Nextcloud file cache (oc_filecache)
• the actual filesystem

Previous occurrence

The same problem happened previously with a real production page named:

Darstellungsvorschlag

The original Collectives page had file/page ID 97724.

After the problem occurred:

SELECT *
FROM oc_collectives_pages
WHERE id = 97724;

returned zero rows.

However, Collectives page versions were still physically available under:

appdata_oceffild2j99/collectives/versions/15/97724/

and could be used to recover the page content.

We therefore suspect that the issue has occurred repeatedly and is not limited to the test page.

WebDAV observation

The affected user mounts Nextcloud through GNOME Online Accounts / GNOME Files (WebDAV).

During our investigation we observed WebDAV requests to the Collectives storage, for example:

/remote.php/dav/files/andre.eberle/.Collectives/TestKollektive/Testseite/Readme.md

We initially suspected that WebDAV access might trigger the problem.

However, we performed a controlled follow-up test:

1. Disconnect GNOME Online Accounts / WebDAV.
2. Create another Collectives page.
3. Publicly share the page.
4. Verify oc_collectives_pages and oc_filecache.
5. Re-enable GNOME Online Accounts.
6. Browse .Collectives through GNOME Files.
7. Open the physical Readme.md via WebDAV.
8. Access the page through Collectives and the public link.

The new test page remained healthy.

Therefore WebDAV access may be related, but we cannot currently confirm it as the trigger.

Healthy control case

A second test page currently remains healthy:

• page_id: 170
• file_id: 104627
• directory ID: 104629
• slug: Test

Current state:

page_id | file_id | slug | cached_fileid | path
--------+---------+------+---------------+----------------------------------------------------
170     | 104627  | Test | 104627        | appdata_oceffild2j99/collectives/18/Test/Readme.md

This remains valid even after reconnecting GNOME Online Accounts and opening the Markdown file through WebDAV.

Logs

For the healthy control page we can see regular WebDAV access such as:

PROPFIND /remote.php/dav/files/andre.eberle/.Collectives/TestKollektive/Test/Readme.md

and:

GET /remote.php/dav/files/andre.eberle/.Collectives/TestKollektive/Test/Readme.md

Nextcloud Text simultaneously accesses the same file using:

/apps/text/session/104627/create

For the broken test case, Collectives eventually reports that the referenced file ID cannot be found.

We can provide relevant full Nextcloud log excerpts if required.

Expected behavior

Creating a public link for a Collectives page must not cause the page's underlying filecache entry to disappear.

The page should remain accessible in Collectives regardless of whether it is:

• publicly shared
• accessed through the public link
• accessed through WebDAV
• accessed through GNOME Files

Actual behavior

For the affected user, publicly shared Collectives pages can later become inaccessible.

The Markdown file remains physically present, but its oc_filecache entry disappears while Collectives still references the old file_id.

This results in:

Could not fetch page

or:

File not found: <file_id>

Additional information

We updated all Nextcloud apps before the controlled test and ran:

occ maintenance:repair --include-expensive

Collectives was updated to 4.5.0.

The issue still occurred afterwards.

We spent considerable time debugging this together with the affected user on the production instance. The exact operation that removes the oc_filecache entry has not yet been identified.

The main question for the Collectives developers is:

Which Collectives / Files / WebDAV code path could remove or invalidate the oc_filecache entry for Readme.md while leaving both the physical file and the oc_collectives_pages.file_id reference intact?

We would be happy to provide targeted additional diagnostics if the developers can point us to the relevant code path or logging that should be enabled.

The report names no source files or tests; start by reproducing the public-share and WebDAV sequence while comparing oc_collectives_pages, oc_filecache, and filesystem state. Trace the operation that removes or invalidates Readme.md's cache entry, then verify that shared pages remain accessible and do not retain dangling file_id references.