[Bug]: WebDAV: curl upload to public File Drop share fails with "nickname header is required" in NC32 despite header being present

[joeheaven]

⚠️ This issue respects the following points: ⚠️

• This is a bug, not a question or a configuration/webserver/proxy issue.
• This issue is not already reported on Github OR Nextcloud Community Forum (I've searched it).
• Nextcloud Server is up to date. See Maintenance and Release Schedule for supported versions.
• I agree to follow Nextcloud's Code of Conduct.

Bug description

Since updating from Nextcloud 31 to Nextcloud 32, a curl script that was previously working to upload files to a public "File Drop" share now consistently fails.

The server responds with a 400 Bad Request and the error message: A nickname header is required when uploading subfolders.

This error occurs even when the nickname header (or X-Nickname) is correctly provided in the request. Extensive diagnostics have proven that the header is being correctly received by the PHP environment, but it appears to be ignored by the Nextcloud application logic for this specific WebDAV endpoint.

Steps to reproduce

1. In the Nextcloud Web UI, create a public share link for any folder and configure it as "File Drop (upload only)".
2. Note the share token from the URL (e.g., ABCDEFGH123456).
3. On a client machine, attempt to upload a file using a curl command like the one below:

curl -v -T "mytestfile.zip" \
-u "SHARE_TOKEN:" \
-H 'X-Requested-With: XMLHttpRequest' \
-H 'nickname: my-nickname' \
"https://yournextcloud.tld/public.php/webdav/mytestfile.zip"

Expected behavior

The file should be successfully uploaded to the shared folder, resulting in an HTTP 201 Created status code.

Nextcloud Server version

32

Operating system

Debian/Ubuntu

PHP engine version

PHP 8.2

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?

None

What user-backends are you using?

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

Configuration report

sudo -u www-data php occ config:list system
{
    "system": {
        "overwriteprotocol": "https",
        "overwritehost": "nextcloud.domain.de",
        "overwrite.cli.url": "https:\/\/nextcloud.domain.de",
        "trusted_proxies": "***REMOVED SENSITIVE VALUE***",
        "forwarded_for_headers": [
            "HTTP_X_FORWARDED_FOR"
        ],
        "instanceid": "***REMOVED SENSITIVE VALUE***",
        "passwordsalt": "***REMOVED SENSITIVE VALUE***",
        "secret": "***REMOVED SENSITIVE VALUE***",
        "trusted_domains": [
            "mynextcloud",
            "nextcloud.domain.de"
        ],
        "datadirectory": "***REMOVED SENSITIVE VALUE***",
        "dbtype": "mysql",
        "version": "32.0.1.2",
        "dbname": "***REMOVED SENSITIVE VALUE***",
        "dbhost": "***REMOVED SENSITIVE VALUE***",
        "dbport": "",
        "dbtableprefix": "oc_",
        "mysql.utf8mb4": true,
        "dbuser": "***REMOVED SENSITIVE VALUE***",
        "dbpassword": "***REMOVED SENSITIVE VALUE***",
        "installed": true,
        "memcache.local": "OC\\Memcache\\APCu",
        "memcache.locking": "OC\\Memcache\\APCu",
        "default_phone_region": "DE",
        "mail_smtpmode": "smtp",
        "mail_sendmailmode": "smtp",
        "mail_from_address": "***REMOVED SENSITIVE VALUE***",
        "mail_domain": "***REMOVED SENSITIVE VALUE***",
        "mail_smtpauth": 1,
        "mail_smtphost": "***REMOVED SENSITIVE VALUE***",
        "mail_smtpport": "587",
        "mail_smtpname": "***REMOVED SENSITIVE VALUE***",
        "mail_smtppassword": "***REMOVED SENSITIVE VALUE***",
        "maintenance": false,
        "skeletondirectory": "",
        "log_type": "file",
        "logfile": "\/media\/usb\/nc-data\/nextcloud.log",
        "loglevel": 2,
        "debug": false,
        "theme": "",
        "updater.release.channel": "stable",
        "maintenance_window_start": 1,
        "data-fingerprint": "2827a19169bb66ba539c1b8d2332a952",
        "versions_retention_obligation": "auto"
    }
}

List of activated Apps

sudo -u www-data php occ app:list
Enabled:
  - activity: 5.0.0-dev.0
  - bookmarks: 16.0.1
  - bruteforcesettings: 5.0.0-dev.0
  - calendar: 6.0.3
  - circles: 32.0.0
  - cloud_federation_api: 1.16.0
  - comments: 1.22.0
  - contacts: 8.0.6
  - dashboard: 7.12.0
  - dav: 1.34.2
  - deck: 1.16.0
  - federatedfilesharing: 1.22.0
  - federation: 1.22.0
  - files: 2.4.0
  - files_accesscontrol: 3.0.1
  - files_downloadlimit: 5.0.0-dev.0
  - files_external: 1.24.0
  - files_pdfviewer: 5.0.0-dev.0
  - files_reminders: 1.5.0
  - files_sharing: 1.24.0
  - files_trashbin: 1.22.0
  - files_versions: 1.25.0
  - firstrunwizard: 5.0.0-dev.0
  - logreader: 5.0.0-dev.0
  - lookup_server_connector: 1.20.0
  - nextcloud_announcements: 4.0.0-dev.0
  - notes: 4.12.3
  - notifications: 5.0.0-dev.0
  - oauth2: 1.20.0
  - password_policy: 4.0.0-dev.0
  - phonetrack: 0.9.1
  - photos: 5.0.0-dev.1
  - privacy: 4.0.0-dev.0
  - profile: 1.1.0
  - provisioning_api: 1.22.0
  - qownnotesapi: 25.8.0
  - recommendations: 5.0.0-dev.0
  - related_resources: 3.0.0-dev.0
  - serverinfo: 4.0.0-dev.0
  - settings: 1.15.1
  - sharebymail: 1.22.0
  - support: 4.0.0-dev.0
  - survey_client: 4.0.0-dev.0
  - systemtags: 1.22.0
  - tasks: 0.17.1
  - text: 6.0.1
  - theming: 2.7.0
  - twofactor_backupcodes: 1.21.0
  - twofactor_totp: 14.0.0
  - updatenotification: 1.22.0
  - user_status: 1.12.0
  - viewer: 5.0.0-dev.0
  - weather_status: 1.12.0
  - webhook_listeners: 1.3.0
  - workflowengine: 2.14.0
Disabled:
  - admin_audit: 1.22.0
  - app_api: 32.0.0 (installed 5.0.2)
  - contactsinteraction: 1.13.1 (installed 1.10.0)
  - encryption: 2.20.0
  - suspicious_login: 10.0.0-dev.0 (installed 4.3.0)
  - twofactor_nextcloud_notification: 6.0.0-dev.0
  - user_ldap: 1.23.0

Nextcloud Signing status

No errors have been found.

Nextcloud Logs

<?xml version="1.0" encoding="utf-8"?>
<d:error xmlns:d="DAV:" xmlns:s="http://sabredav.org/ns">
  <s:exception>Sabre\DAV\Exception\BadRequest</s:exception>
  <s:message>A nickname header is required when uploading subfolders</s:message>
</d:error>

Note: The main nextcloud.log file, even with 'loglevel' => 0 and 'debug' => true, did not provide any further details or log the incoming request headers during the failed PUT request.

Additional info

This issue was extensively troubleshot to definitively rule out environmental or configuration problems. The evidence strongly indicates the bug is within the Nextcloud application.

Proof:

We created a simple PHP debug script (headers.php) in the Nextcloud webroot to inspect the headers being received by the PHP engine.

Debug Script (headers.php):

php

$value) { if (substr($key, 0, 5) === 'HTTP_') { echo "$key = $value\n"; } } echo "\n--- Other Variables ---\n"; echo "REQUEST_METHOD = " . ($_SERVER['REQUEST_METHOD'] ?? 'Not set') . "\n"; ?>

We then executed a PUT request to this script, mimicking the failed upload:
curl -k -X PUT -H 'nickname: ThisIsThePutTest' -d "" "https://nextcloud.domain.de/headers.php"

Result from the Debug Script:

text
--- PHP $_SERVER array for PUT request ---

HTTP_NICKNAME = ThisIsThePutTest
HTTP_ACCEPT_ENCODING = gzip
HTTP_X_REAL_IP = ::1
HTTP_X_FORWARDED_PROTO = https
HTTP_X_FORWARDED_HOST = nextcloud.domain.de
HTTP_X_FORWARDED_FOR = ::1
HTTP_VIA = 2.0 Caddy
HTTP_ACCEPT = /
HTTP_USER_AGENT = curl/7.88.1
HTTP_HOST = nextcloud.domain.de

--- Other Variables ---
REQUEST_METHOD = PUT

Conclusion:

The output proves that the web server stack (Caddy -> Apache -> PHP-FPM) is correctly passing the HTTP_NICKNAME header to the PHP environment on a PUT request. Since the simple PHP script receives the header but the Nextcloud WebDAV script at /public.php/webdav/ claims it is missing, the bug must be in how the Nextcloud application code is processing the headers for this specific request type. The issue occurs both when bypassing the proxy and when going through it.

[solracsf]

Duplicate of #55366 ?

[joeheaven]

Duplicate of #55366 ?

I would not think so, it's the same error message, but it could be mitigated by changing some setting and it concerned the web-upload.

Here it is the CLI upload and the workaround does not apply in this case.

[provokateurin]

It might not be an exact duplicate, but it is very likely that it's related.

[jurgennnnn]

Dealing with the same issue right now. So the header is actually X-Nc-Nickname, probably should be documented somewhere...

[rmelotte]

Indeed after providing a X-Nc-Nickname header, the error message is now different:

<?xml version="1.0" encoding="utf-8"?>
<d:error xmlns:d="DAV:" xmlns:s="http://sabredav.org/ns">
  <s:exception>Sabre\DAV\Exception\Conflict</s:exception>
  <s:message>Files cannot be created in non-existent collections</s:message>
</d:error>

For the record I used to be able to upload files to public shares without having to provide any additional header, but this no longer works in NC32.

I'm wondering if, in addition to X-Nc-Nickname, the server expect another header to be set?

[provokateurin]

Both problems should be fixed by #55807

[rmelotte]

Both problems should be fixed by #55807

Nice!
IIUC, it has been backported to stable 32 with #55804 ?
If so, it should be fixed with in the upcoming v32.0.3 release.

[provokateurin]

Yes, exactly :)

[joeheaven]

Just updated to 32.0.3, changed header to include X-Nc-nickname, but the problem is still the same:

<?xml version="1.0" encoding="utf-8"?>
<d:error xmlns:d="DAV:" xmlns:s="http://sabredav.org/ns">
  <s:exception>Sabre\DAV\Exception\Conflict</s:exception>
  <s:message>Files cannot be created in non-existent collections</s:message>
</d:error>

I used the following command:

curl -s -S -k -T ${filename} -u "SECRETTOKEN" -H 'X-Requested-With: XMLHttpRequest' -H 'X-Nc-Nickname: CURL' https://mynextcloud.domain.de/public.php/webdav/${filename}

Any hints what to try next? Maybe the command is not correct now?

[provokateurin]

Same was reported in #56216.

I'll open a new issue about this error, in order to merge the two discussions and also address this new error message which is not strictly related to the first error.