[Bug]: File drop: Files cannot be created in non-existent collections

[provokateurin]

⚠️ 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

Follow up to #56338 and #56216

Steps to reproduce

To be determined.

Expected behavior

No error

Nextcloud Server version

32

Operating system

None

PHP engine version

None

Web server

None

Database engine version

None

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

None

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

List of activated Apps

Nextcloud Signing status

Nextcloud Logs

Additional info

No response

[C0rn3j]

Repro:

touch test
/usr/bin/curl -T test -u g2qefPk3YJe4JJ4: -H 'X-Requested-With: XMLHttpRequest' https://cloud.rys.rs/public.php/webdav/test

<?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>

Note that uploads via browser (https://cloud.rys.rs/s/g2qefPk3YJe4JJ4) work just fine, it's the curl command that breaks it.

[jurgennnnn]

When running Nextcloud using nginx and "Nextcloud in a subdir of the NGINX webroot" configuration from docs, uploading to a file request share kinda works, but files get renamed to whatever is in the nickname header. When uploading to a share with any other permissions in addition to create I get a 403.

When using "Nextcloud in the webroot of NGINX" configuration I get the usual Files cannot be created in non-existent collections error when uploading to a file request share.

[provokateurin]

Hm so this has been broken for a while now. @C0rn3j you can do /usr/bin/curl -T test -H 'X-Requested-With: XMLHttpRequest' https://cloud.rys.rs/public.php/dav/files/g2qefPk3YJe4JJ4/test instead to make it work again.

[C0rn3j]

Looking at my uploaded files and cross-referencing that with package versions, 32.0.1 broke it and 32.0.0 probably still had it working.

So it broke tops circa 2 months ago.

[joeheaven]

Hm so this has been broken for a while now. @C0rn3j you can do /usr/bin/curl -T test -H 'X-Requested-With: XMLHttpRequest' https://cloud.rys.rs/public.php/dav/files/g2qefPk3YJe4JJ4/test instead to make it work again.

That works, at least for the time being that is a solution. Strangely, if you still keep the X-NC-Nickname-Header, a subdirectory with that name is created and the upload goes there.

Thanks @provokateurin for the moment, at least I can upload some backups again!

[provokateurin]

That works, at least for the time being that is a solution. Strangely, if you still keep the X-NC-Nickname-Header, a subdirectory with that name is created and the upload goes there.

Yeah the nickname is always added as a directory parent.