Better error messages for file actions failures

[ai-tp]

⚠️ 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 (I've searched it).
• Nextcloud Server is up to date. See Maintenance and Release Schedule for supported versions.
• Nextcloud Server is running on 64bit capable CPU, PHP and OS.
• I agree to follow Nextcloud's Code of Conduct.

Bug description

File actions via the Webinterface such as delete or move, have a chance of failing.
A popup will appear saying 'Error deleting file "Test".' or 'Could not move "Test"'
The nextcloud log does not log anything when this happens.
The webserver log does provide a hint with:
"PUT /remote.php/webdav/sdufghiusdhgu/file5293.txt HTTP/2.0" 201 0 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/111.0.0.0 Safari/537.36 Edg/111.0.1661.54"
"DELETE /remote.php/dav/files/administrator/sdufghiusdhgu/file5293.txt HTTP/2.0" 423 285 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/111.0.0.0 Safari/537.36 Edg/111.0.1661.54"

The webserver code "423" makes me suspect that the filelocking is not releasing its locks properly.

I also believe that the more performance a system has the less likely the problem is to occur. However due to the random nature of the error I am not certain about that.

Steps to reproduce

1. Upload Folder containing hundreds or even thousands of files
2. Go into folder and select all files
3. Delete files
4. Sometimes some of the files wont get deleted and the error 'Error deleting file "Test".' pops up.

Expected behavior

1. Upload Folder containing hundreds or even thousands of files
2. Go into folder and select all files
3. Delete files
4. All files get deleted reliably or at least the log tells me why it failed

Installation method

Community Manual installation with Archive

Nextcloud Server version

26

Operating system

Debian/Ubuntu

PHP engine version

PHP 8.1

Web server

Nginx

Database engine version

MySQL

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

Fresh Nextcloud Server install

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

{
    "system": {
        "instanceid": "***REMOVED SENSITIVE VALUE***",
        "passwordsalt": "***REMOVED SENSITIVE VALUE***",
        "secret": "***REMOVED SENSITIVE VALUE***",
        "trusted_domains": [
            "***REMOVED SENSITIVE VALUE***"
        ],
        "datadirectory": "***REMOVED SENSITIVE VALUE***",
        "dbtype": "mysql",
        "version": "26.0.0.11",
        "overwrite.cli.url": "https:\/\/***REMOVED SENSITIVE VALUE***",
        "overwritehost": "***REMOVED SENSITIVE VALUE***",
        "overwriteprotocol": "https",
        "dbname": "***REMOVED SENSITIVE VALUE***",
        "dbhost": "***REMOVED SENSITIVE VALUE***",
        "dbport": "3306",
        "dbtableprefix": "oc_",
        "mysql.utf8mb4": true,
        "dbuser": "***REMOVED SENSITIVE VALUE***",
        "dbpassword": "***REMOVED SENSITIVE VALUE***",
        "installed": true,
        "default_phone_region": "de",
        "default_language": "de_DE",
        "default_locale": "de_DE",
        "memcache.local": "\\OC\\Memcache\\APCu",
        "memcache.locking": "\\OC\\Memcache\\Redis",
        "redis": {
            "host": "***REMOVED SENSITIVE VALUE***",
            "port": 0,
            "timeout": 0
        },
        "mail_smtpmode": "smtp",
        "mail_smtpsecure": "tls",
        "mail_sendmailmode": "smtp",
        "mail_from_address": "***REMOVED SENSITIVE VALUE***",
        "mail_domain": "***REMOVED SENSITIVE VALUE***",
        "mail_smtpauthtype": "LOGIN",
        "mail_smtphost": "***REMOVED SENSITIVE VALUE***",
        "mail_smtpport": "587",
        "mail_smtpauth": 1,
        "mail_smtpname": "***REMOVED SENSITIVE VALUE***",
        "mail_smtppassword": "***REMOVED SENSITIVE VALUE***",
        "maintenance": false,
        "theme": "",
        "loglevel": 3,
        "log_authfailip": true,
        "twofactor_enforced": "true",
        "twofactor_enforced_groups": [
            "fatestgroup"
        ],
        "twofactor_enforced_excluded_groups": [
            "admin"
        ],
        "updater.release.channel": "stable",
        "app_install_overwrite": [
            "files_lock",
            "files_pdfviewer",
            "groupfolders",
            "files_antivirus"
        ],
        "allow_local_remote_servers": true,
        "defaultapp": "files",
        "trashbin_retention_obligation": "7, 7",
        "trusted_proxies": "***REMOVED SENSITIVE VALUE***"
    }
}

List of activated Apps

Enabled:
  - activity: 2.18.0
  - admin_audit: 1.16.0
  - bruteforcesettings: 2.6.0
  - calendar: 4.3.1
  - circles: 26.0.0
  - cloud_federation_api: 1.9.0
  - comments: 1.16.0
  - contacts: 5.2.0
  - contactsinteraction: 1.7.0
  - dashboard: 7.6.0
  - dav: 1.25.0
  - external: 5.1.0
  - federatedfilesharing: 1.16.0
  - federation: 1.16.0
  - files: 1.21.1
  - files_accesscontrol: 1.16.0
  - files_antivirus: 4.0.3
  - files_automatedtagging: 1.16.1
  - files_downloadactivity: 1.16.0
  - files_external: 1.18.0
  - files_lock: 26.0.0
  - files_pdfviewer: 2.7.0
  - files_retention: 1.15.0
  - files_rightclick: 1.5.0
  - files_sharing: 1.18.0
  - files_trashbin: 1.16.0
  - files_versions: 1.19.1
  - firstrunwizard: 2.15.0
  - forms: 3.2.0
  - group_default_quota: 0.1.6
  - groupfolders: 14.0.0
  - logreader: 2.11.0
  - lookup_server_connector: 1.14.0
  - mail: 3.0.2
  - nextcloud_announcements: 1.15.0
  - notifications: 2.14.0
  - notify_push: 0.6.2
  - oauth2: 1.14.0
  - password_policy: 1.16.0
  - photos: 2.2.0
  - privacy: 1.10.0
  - provisioning_api: 1.16.0
  - recommendations: 1.5.0
  - related_resources: 1.1.0-alpha1
  - richdocuments: 8.0.0
  - serverinfo: 1.16.0
  - settings: 1.8.0
  - sharebymail: 1.16.0
  - spreed: 16.0.2
  - support: 1.9.0
  - survey_client: 1.14.0
  - systemtags: 1.16.0
  - text: 3.7.2
  - theming: 2.1.1
  - twofactor_admin: 4.1.9
  - twofactor_backupcodes: 1.15.0
  - twofactor_email: 2.7.2
  - updatenotification: 1.16.0
  - user_status: 1.6.0
  - viewer: 1.10.0
  - weather_status: 1.6.0
  - workflowengine: 2.8.0
Disabled:
  - drawio: 2.1.0 (installed 2.1.0)
  - electronicsignatures: 2.0.3 (installed 2.0.3)
  - encryption: 2.14.0 (installed 2.12.0)
  - files_fulltextsearch: 25.0.0 (installed 25.0.0)
  - fulltextsearch: 25.0.0 (installed 25.0.0)
  - fulltextsearch_elasticsearch: 25.0.0 (installed 25.0.0)
  - impersonate: 1.13.0 (installed 1.13.0)
  - richdocumentscode: 22.5.802 (installed 22.5.802)
  - suspicious_login: 4.4.0 (installed 4.1.0)
  - theming_customcss: 1.13.0 (installed 1.13.0)
  - twofactor_totp: 8.0.0-alpha.0 (installed 8.0.0-alpha.0)
  - user_ldap: 1.16.0 (installed 1.16.0)

Nextcloud Signing status

No errors have been found.

Nextcloud Logs

Empty Logs

Additional info

I also encountered the issue on a nextcloud v25 kubernetes cluster, nextcloud v25 aio, aswell as the most simplistic lamp stack installation I could think of . Which makes me suspect the issue can be reproduced on any setup.

[skjnldsv]

Hin I understand :)
But you haven't answered my question, what are your expectations. Some files might be locked (like your example with error 423). When selection multiple files, in which one is locked, what do you expect to see in the web interface?

• Not being able to execute the action if at least one file is locked?
• Still being able to execute but show an error if it fails?
• Something else?

[ai-tp]

Hi,
Yes, the log should show something like like "Could not delete file x because it is locked by x"
However, to clarify, this problem occurs even in a test environment where I am the only user.
I dont see a reason for nextcloud to lock the files and prevent me from working with them in this scenario.
Which is why I am thinking this is a bug. But perhaps I am missing something?

[ai-tp]

Since both tags and title were changed, this is not considered a bug?

[skjnldsv]

It's an enhancement. We do warn already if something goes wrong.
You're asking for more verbose explanations, so I consider this as a user experience enhancement :)

[ai-tp]

Perhaps that was a misscommunication. More verbose explanations would be appreciated.
However I made this bug report, because I believe this is a bug and was hoping it could be fixed.

[solracsf]

In a single user instance, file locking can be disabled without any risk.
Or, at least, lower down its TTL. See:

server/config/config.sample.php

Lines 2090 to 2113 in 598859d

	/**
	* Enables transactional file locking.
	* This is enabled by default.
	*
	* Prevents concurrent processes from accessing the same files
	* at the same time. Can help prevent side effects that would
	* be caused by concurrent operations. Mainly relevant for
	* very large installations with many users working with
	* shared files.
	*
	* Defaults to ``true``
	*/
	'filelocking.enabled' => true,
	/**
	* Set the lock's time-to-live in seconds.
	*
	* Any lock older than this will be automatically cleaned up.
	*
	* Defaults to ``60*60`` seconds (1 hour) or the php
	* max_execution_time, whichever is higher.
	*/
	'filelocking.ttl' => 60*60,

[ai-tp]

Thank you for the tip. However the single user environment I mentioned is a testing environment. The bug can occur in any environment, which sadly includes production servers with many users.