Public share access broken with "No read permissions" (Forbidden) when Terms of Service app is enabled for public shares

Is this the first time you've seen this error?

Yes - this configuration (terms_of_service + tos_on_public_shares=1 on public link shares) worked correctly for a long time and only broke after upgrading Nextcloud.

Steps to reproduce

1. Enable the terms_of_service app.
2. Set tos_on_public_shares to 1:

   ./occ config:app:set terms_of_service tos_on_public_shares --value '1'
   

3. Create a public link share of a folder (tested both with and without a password on the share — behavior is identical).
4. Open the public share link as an anonymous guest (no Nextcloud account, no login).
5. Observe the Terms of Service dialog.
6. Accept it (and, if the share is password-protected, then enter the share password).

Expected behaviour

After accepting the Terms of Service (and entering the share password, if set), the guest should see the shared folder contents.

Actual behaviour

• The Terms of Service dialog reappears a second time immediately after accepting it (and after the password prompt, when a password is set).
• The share ultimately fails to load any folder/file listing. The UI shows a generic error:

  Diese Operation ist nicht erlaubt
  

  ("This operation is not allowed")
• Direct file download via the "Download" button in the share UI still works, but folder/file listing (PROPFIND) does not.
• The following exception is returned by the WebDAV endpoint instead of the expected TermsNotSignedException:

  <?xml version="1.0" encoding="utf-8"?>
  <d:error xmlns:d="DAV:" xmlns:s="http://sabredav.org/ns" xmlns:o="http://owncloud.org/ns">
    <s:exception>OCA\DAV\Connector\Sabre\Exception\Forbidden</s:exception>
    <s:message>No read permissions</s:message>
    <o:retry xmlns:o="o:">false</o:retry>
    <o:reason xmlns:o="o:">No read permissions</o:reason>
  </d:error>
  

• Browser console shows a 401 on the terms acceptance endpoint:

  /ocs/v2.php/apps/terms_of_service/sign:1  Failed to load resource: the server responded with a status of 401 ()
  

Troubleshooting already performed (ruled out as causes)

• Filesystem permissions on the shared folder and its parents — all correct (drwxr-xr-x throughout).
• php occ files:scan --all — 0 changes, filecache already consistent.
• oc_flow_operations table (files_accesscontrol / Workflow rules) — empty, no active rules.
• Recreated the public share from scratch — same error on the brand-new share.
• Removed all custom share permissions, set share back to default "View only" — same error.
• Disabled and re-enabled the terms_of_service app — same error.
• Ran php occ app:update terms_of_service — reports app is already up to date.
• Verified terms_of_service version (4.7.1) is the official released version for the installed Nextcloud major version according to the Nextcloud App Store.
• Confirmed the problem is not related to nginx/webserver-level blocking: a direct curl -X PROPFIND request against /public.php/dav/files/<token>/ reaches Sabre/Nextcloud correctly and returns the DAV error above (i.e. nginx passes the request through fine).
• Confirmed the issue occurs identically with and without a password set on the share.
• Temporarily disabling terms_of_service entirely makes the public share work again immediately — strongly indicating the app (or its interaction with the current server version) is the root cause.

Server configuration

• Nextcloud version: upgraded from 32.0.11.1 → 32.0.12.1, then later to 34.0.1 (Hub 26 Spring). Issue present on both 32.0.12 and 34.0.1.
• terms_of_service app version: 4.7.1 (installed 4.7.1)
• tos_on_public_shares: 1
• tos_for_users: default
• Web server: nginx (managed/shared hosting via ISPConfig)
• PHP: 8.3
• Database: MySQL

Current workaround

We have disabled the terms_of_service app entirely and replaced it with a custom static HTML "consent" page hosted outside of Nextcloud, which guests must click through before being redirected to the actual share link. This is not sustainable long-term for us as we operate many separate public shares with different links.

Reproduce the issue with terms_of_service enabled, tos_on_public_shares=1, and an anonymous public share. Start by tracing the /ocs/v2.php/apps/terms_of_service/sign response and the PROPFIND request to /public.php/dav/files//. Done means accepting the terms once allows the guest to list the shared folder, including for password-protected shares.