[Bug]: Public share of a Team Folder intermittently reports zero available quota and hides the "+New" button despite successful WebDAV writes

⚠️ This issue respects the following points: ⚠️

• This is not a troubleshooting question, general support matter, or webserver/proxy problem, but likely a bug (if unsure, ask the Community Help Forum).
• This issue is not already reported on Github OR solved at the Community Help Forum (I've searched!).
• I'm using a maintained major version of Nextcloud Server and tested against the latest patch level. (Supported major versions and current patch levels).
• I agree to follow Nextcloud's Code of Conduct.
• I've tried my best to provide clear reproduction steps that someone unfamiliar with this bug could use to reproduce it.

Bug description

On Nextcloud Server 34.0.3, a public link share for a nested folder inside a Team Folder intermittently reports zero available quota through public WebDAV, even though:

• the Team Folder has a quota of 10 GiB;
• the public share is configured with Can edit;
• the share record has permissions: 31;
• creating a folder through WebDAV succeeds with 201 Created.

When the problem occurs, the public Files interface does not show the +New button, so the guest cannot upload files or create folders through the web interface.

The root PROPFIND request for the public share returns:

<d:quota-available-bytes>0</d:quota-available-bytes>

The user who created the share intentionally has a personal quota of 0 B. Users on this instance are not allowed to store files in their personal space; they are only allowed to create files in Team Folders.

The Team Folder itself has a configured quota of 10 GiB.

The permissions of the public share are saved correctly. Running:

sudo -u www-data php occ sharing:list

shows that the share permissions change from:

"permissions": 1

to:

"permissions": 31

when the link is changed from View only to Can edit.

Despite the quota-available-bytes value being zero, a direct MKCOL request to the same public WebDAV share succeeds:

HTTP/2 201 Created

Immediately after the successful MKCOL request, the next PROPFIND request returns the Team Folder quota:

<d:quota-available-bytes>10737418240</d:quota-available-bytes>

After that, the +New button appears in the public Files interface.

This indicates that the Team Folder is writable and has available space. The incorrect zero value appears to affect only the quota property returned by PROPFIND and the frontend state derived from it.

The behavior is intermittent. Switching the public share between View only and Can edit, and then opening the link in a new incognito/private browser session, may either reproduce the problem or temporarily make it disappear.

I have observed similar behavior on Nextcloud major versions 32, 33, and 34. The detailed reproduction and diagnostics in this report were performed on Nextcloud Server 34.0.3.

Steps to reproduce

1. Configure a user with a personal quota of 0 B.

2. Create a Team Folder and configure its quota as 10 GiB.

3. Grant the user permission to create and modify files inside the Team Folder.

4. Create a nested folder inside the Team Folder.

5. Create a public link share for the nested folder.

6. Configure the public link as Can edit.
   The following sharing options are enabled on the instance:

   • password protection is required;
   • an expiration date is required;
   • users are allowed to set custom public-share tokens.

7. Verify the public share with:

   sudo -u www-data php occ sharing:list
   

   The share should have:

   "permissions": 31
   

8. Open the public link in a new incognito/private browser session.

9. Inspect the root public WebDAV PROPFIND request:

   /public.php/dav/files/<share-token>/
   

10. When the bug occurs, observe:

    <d:quota-available-bytes>0</d:quota-available-bytes>
    

    The +New button is not displayed in the public Files interface.

11. Without changing the share permissions, send an MKCOL request to create a test directory inside the public share:

    MKCOL /public.php/dav/files/<share-token>/<test-directory>
    

12. Observe that the server returns:

    HTTP/2 201 Created
    

13. Reload the public page or repeat the root PROPFIND request.

14. Observe that the response now contains:

    <d:quota-available-bytes>10737418240</d:quota-available-bytes>
    

15. Observe that the +New button is now displayed.

Expected behavior

A public editable share pointing to a folder inside a Team Folder should consistently report the available quota of the Team Folder.

The personal quota of the user who created the public share should not be returned for the shared Team Folder path.

When the public share has create permissions and the Team Folder has available space:

• quota-available-bytes should not be 0;
• the +New button should be displayed;
• the frontend should not require a prior WebDAV write operation before detecting the correct Team Folder quota.

For this test environment, the expected value for an empty Team Folder with a 10 GiB quota is:

<d:quota-available-bytes>10737418240</d:quota-available-bytes>

Nextcloud Server version

34

Operating system

Debian/Ubuntu

PHP engine version

PHP 8.5

Web server

Apache (supported)

Database engine version

MariaDB

Is this bug present after an update or on a fresh install?

Upgraded to a MAJOR version (ex. 31 to 32)

Are you using the Nextcloud Server Encryption module?

Encryption is Disabled

What user-backends are you using?

• Default user-backend (database)
• LDAP/ Active Directory
• SSO - SAML
• Other

Configuration report

{
    "system": {
        "passwordsalt": "***REMOVED SENSITIVE VALUE***",
        "secret": "***REMOVED SENSITIVE VALUE***",
        "trusted_domains": [
            "***REMOVED SENSITIVE VALUE***"
        ],
        "trusted_proxies": "***REMOVED SENSITIVE VALUE***",
        "forwarded_for_headers": [
            "HTTP_X_FORWARDED_FOR"
        ],
        "overwritehost": "***REMOVED SENSITIVE VALUE***",
        "overwriteprotocol": "https",
        "datadirectory": "***REMOVED SENSITIVE VALUE***",
        "overwrite.cli.url": "***REMOVED SENSITIVE VALUE***",
        "dbtype": "mysql",
        "version": "34.0.3.2",
        "dbname": "***REMOVED SENSITIVE VALUE***",
        "dbhost": "***REMOVED SENSITIVE VALUE***",
        "dbport": "",
        "dbtableprefix": "oc_",
        "dbuser": "***REMOVED SENSITIVE VALUE***",
        "dbpassword": "***REMOVED SENSITIVE VALUE***",
        "installed": true,
        "instanceid": "***REMOVED SENSITIVE VALUE***",
        "has_internet_connection": true,
        "ldapIgnoreNamingRules": false,
        "ldapProviderFactory": "\\OCA\\User_LDAP\\LDAPProviderFactory",
        "mail_from_address": "***REMOVED SENSITIVE VALUE***",
        "mail_smtpmode": "smtp",
        "mail_smtpauthtype": "LOGIN",
        "skeletondirectory": "",
        "lost_password_link": "disabled",
        "updater.release.channel": "stable",
        "maintenance": false,
        "theme": "",
        "loglevel": 2,
        "auth.webauthn.enabled": false,
        "simpleSignUpLink.shown": false,
        "mysql.utf8mb4": true,
        "memcache.local": "\\OC\\Memcache\\APCu",
        "memcache.distributed": "\\OC\\Memcache\\Redis",
        "filelocking.enabled": true,
        "memcache.locking": "\\OC\\Memcache\\Redis",
        "redis": {
            "host": "***REMOVED SENSITIVE VALUE***",
            "port": 0,
            "timeout": 0
        },
        "activity_use_cached_mountpoints": true,
        "activity_expire_days": 365,
        "twofactor_enforced": "false",
        "twofactor_enforced_groups": [],
        "twofactor_enforced_excluded_groups": [],
        "maintenance_window_start": 1,
        "default_phone_region": "***REMOVED SENSITIVE VALUE***",
        "app_install_overwrite": [
            "sharelisting"
        ],
        "upgrade.disable-web": false,
        "files.chunked_upload.max_size": 0,
        "updater.secret": "***REMOVED SENSITIVE VALUE***"
    }
}

List of activated Apps

Enabled:
  - activity: 7.0.0
  - appstore: 1.0.0
  - bruteforcesettings: 7.0.0
  - cloud_federation_api: 1.18.0
  - comments: 1.24.0
  - contactsinteraction: 1.15.0
  - dav: 1.40.0
  - federatedfilesharing: 1.24.0
  - federation: 1.24.0
  - files: 2.6.0
  - files_automatedtagging: 5.0.0
  - files_downloadlimit: 5.2.0
  - files_lock: 34.0.1
  - files_pdfviewer: 7.0.0-dev.0
  - files_reminders: 1.7.0
  - files_retention: 5.0.0
  - files_sharing: 1.26.0
  - groupfolders: 22.0.6
  - logreader: 7.0.0
  - lookup_server_connector: 1.22.0
  - notifications: 7.0.0-dev.1
  - oauth2: 1.22.0
  - password_policy: 6.0.0-dev.0
  - privacy: 6.0.0-dev.1
  - profile: 1.3.0
  - provisioning_api: 1.24.0
  - related_resources: 5.0.0-dev.0
  - serverinfo: 6.0.0
  - settings: 1.17.0
  - sharelisting: 1.3.0
  - systemtags: 1.24.0
  - text: 8.0.0
  - theming: 2.9.0
  - theming_customcss: 1.21.0
  - twofactor_admin: 4.12.0
  - twofactor_backupcodes: 1.23.0
  - twofactor_totp: 16.0.0
  - updatenotification: 1.24.0
  - user_ldap: 1.25.0
  - user_usage_report: 5.0.2
  - viewer: 7.0.0-dev.0
  - webhook_listeners: 1.6.0
  - workflowengine: 2.16.0
Disabled:
  - admin_audit: 1.24.0 (installed 1.8.0)
  - app_api: 34.0.0 (installed 4.0.3)
  - cfg_share_links: 7.0.1 (installed 7.0.1)
  - circles: 34.0.0 (installed 27.0.0)
  - dashboard: 7.14.0 (installed 7.0.0)
  - encryption: 2.22.0
  - files_external: 1.26.0
  - files_rightclick: 0.15.1 (installed 1.6.0)
  - files_trackdownloads: 1.11.0 (installed 1.11.0)
  - files_trashbin: 1.24.0 (installed 1.8.0)
  - files_versions: 1.27.0 (installed 1.11.0)
  - firstrunwizard: 7.0.0-dev.0 (installed 4.0.0)
  - nextcloud_announcements: 6.0.0 (installed 1.13.0)
  - office: 1.0.0 (installed 1.0.0)
  - photos: 7.0.0 (installed 1.6.0)
  - recommendations: 7.0.0 (installed 1.3.0)
  - sharebymail: 1.24.0 (installed 1.3.0)
  - sharerenamer: 3.5.0 (installed 3.5.0)
  - support: 6.0.0 (installed 1.7.0)
  - survey_client: 6.0.0-dev.0 (installed 4.0.0)
  - suspicious_login: 12.0.0-dev.0
  - twofactor_nextcloud_notification: 8.0.0
  - user_status: 1.14.0 (installed 1.0.1)
  - weather_status: 1.14.0 (installed 1.4.0)

Nextcloud Signing status

Nextcloud Logs

No relevant errors or warnings are written to `nextcloud.log` when the problem occurs.

Additional info

The successful MKCOL response demonstrates that this is not an actual permission failure or an actual out-of-space condition.

The immediate change from:

<d:quota-available-bytes>0</d:quota-available-bytes>

to:

<d:quota-available-bytes>10737418240</d:quota-available-bytes>

after a write operation suggests a problem with quota-context selection, cached storage information, or cache invalidation for public WebDAV shares backed by Team Folders.

This is only an observation based on the reproduction results; the exact cause has not been confirmed.

Reproduce the issue through the public WebDAV endpoint using the root PROPFIND and subsequent MKCOL requests, and compare the quota values before and after the write. Use occ sharing:list to verify the share permissions and trace the Team Folder quota context used for the public share. Done means PROPFIND consistently reports the Team Folder quota and the public Files interface shows +New without requiring a prior write.