[Bug]: files_versions metadata update forbidden on new file upload in a read-create-only share resulting in errors

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

When using a read-create-only share (no edit, no delete) for every new file added an error is thrown in the logs, resulting in a large amount of log spam. Adding 1000 files means 1000 errors, which makes it very hard to track real errors as it adds a lot of noise.

Forbidden You cannot update the version's metadata because you do not have update permissions on the source file.
Exception thrown: OCA\DAV\Connector\Sabre\Exception\Forbidden

Relevant code is https://github.com/nextcloud/server/blob/master/apps/files_versions/lib/Versions/LegacyVersionsBackend.php#L312. The code appears to be hardcoded to check for the update permission. However for newly created files checking for the create permission seems appropriate instead.

public function setMetadataValue(Node $node, int $revision, string $key, string $value): void {
	if (!$this->currentUserHasPermissions($node, Constants::PERMISSION_UPDATE)) {
		throw new Forbidden('You cannot update the version\'s metadata because you do not have update permissions on the source file.');
	}

Steps to reproduce

First create a share that is read-create only, such as the below. Edit and delete are not allowed.

Then using Nextcloud desktop sync client (browser not tested) add some new files to path with the user that has received the share. For example by pasting some files in this folder. Errors immediately show up in server logs.

Expected behavior

The metadata update on file creation should be allowed with the create permission when the file is initially created. No errors as a result.

Nextcloud Server version

30

Operating system

Debian/Ubuntu

PHP engine version

PHP 8.2

Web server

Nginx

Database engine version

PostgreSQL

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

No errors have been found.

Nextcloud Logs

Additional info

The naming of the implementation LegacyVersionsBackend.php suggests there might be another implementation available. I tried searching for this but unfortunately could not find any. Possibly something on the roadmap?

I could share additional information but as I have found the relevant line in repository and the cause is very straightforward I chose not to for now out of privacy concerns.

Edit: I am not familiar with the core file upload/chunk-move logic. Reading the source code it seems that it might be difficult to differentiate between file create and file update inside LegacyVersionsBackend.php. An alternative solution might be to allow the metadata update always if the current metadata is empty, which should only be true with a newly created file? Thoughts on this would be appreciated.

Thanks!

Start in apps/files_versions/lib/Versions/LegacyVersionsBackend.php at setMetadataValue(), then trace the file upload and chunk-move path to determine how creation and update permissions are distinguished. Reproduce with a read-create-only share and the desktop sync client; done means new uploads no longer generate forbidden metadata-update errors or log spam.