[Bug]: Can't edit/delete files copied from read-only shared folders

[chapa]

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

This has already been mentioned on the forum (link), but I'm creating an issue here because it's more likely to be a bug than a support request.

When a user copies a file from a read-only (internal) shared folder to its home folder, the file seems to stay in a read-only state and cannot be updated nor deleted.

Steps to reproduce

1. As user1, create a folder and a file within
2. Share the folder to user2
3. As user2, copy the file from the shared folder to the root of the home folder

Expected behavior

The copied file should be editable and it should be possible to delete it

Nextcloud Server version

29

Operating system

Debian/Ubuntu

PHP engine version

PHP 8.2

Web server

Apache (supported)

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?

Encryption is Disabled

What user-backends are you using?

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

Configuration report

{
    "system": {
        "htaccess.RewriteBase": "\/",
        "memcache.local": "\\OC\\Memcache\\APCu",
        "apps_paths": [
            {
                "path": "\/var\/www\/html\/apps",
                "url": "\/apps",
                "writable": false
            },
            {
                "path": "\/var\/www\/html\/custom_apps",
                "url": "\/custom_apps",
                "writable": true
            }
        ],
        "upgrade.disable-web": true,
        "instanceid": "***REMOVED SENSITIVE VALUE***",
        "passwordsalt": "***REMOVED SENSITIVE VALUE***",
        "secret": "***REMOVED SENSITIVE VALUE***",
        "trusted_domains": [
            "localhost:8080"
        ],
        "datadirectory": "***REMOVED SENSITIVE VALUE***",
        "dbtype": "mysql",
        "version": "29.0.14.1",
        "overwrite.cli.url": "http:\/\/localhost:8080",
        "dbname": "***REMOVED SENSITIVE VALUE***",
        "dbhost": "***REMOVED SENSITIVE VALUE***",
        "dbport": "",
        "dbtableprefix": "oc_",
        "mysql.utf8mb4": true,
        "dbuser": "***REMOVED SENSITIVE VALUE***",
        "dbpassword": "***REMOVED SENSITIVE VALUE***",
        "installed": true
    }
}

List of activated Apps

Enabled:
  - activity: 2.21.1
  - circles: 29.0.0-dev
  - cloud_federation_api: 1.12.0
  - comments: 1.19.0
  - contactsinteraction: 1.10.0
  - dashboard: 7.9.0
  - dav: 1.30.1
  - federatedfilesharing: 1.19.0
  - federation: 1.19.0
  - files: 2.1.1
  - files_downloadlimit: 2.0.0
  - files_pdfviewer: 2.10.0
  - files_reminders: 1.2.0
  - files_sharing: 1.21.0
  - files_trashbin: 1.19.0
  - files_versions: 1.22.0
  - firstrunwizard: 2.18.0
  - logreader: 2.14.0
  - lookup_server_connector: 1.17.0
  - nextcloud_announcements: 1.18.0
  - notifications: 2.17.0
  - oauth2: 1.17.1
  - password_policy: 1.19.0
  - photos: 2.5.0
  - privacy: 1.13.0
  - provisioning_api: 1.19.0
  - recommendations: 2.1.0
  - related_resources: 1.4.0
  - serverinfo: 1.19.0
  - settings: 1.12.0
  - sharebymail: 1.19.0
  - support: 1.12.0
  - survey_client: 1.17.0
  - systemtags: 1.19.0
  - text: 3.10.1
  - theming: 2.4.0
  - twofactor_backupcodes: 1.18.0
  - updatenotification: 1.19.1
  - user_status: 1.9.0
  - viewer: 2.3.0
  - weather_status: 1.9.0
  - workflowengine: 2.11.0
Disabled:
  - admin_audit: 1.19.0
  - bruteforcesettings: 2.9.0
  - encryption: 2.17.0
  - files_external: 1.21.0
  - suspicious_login: 7.0.0
  - twofactor_totp: 11.0.0-dev
  - user_ldap: 1.20.0

Nextcloud Signing status

No errors have been found.

Nextcloud Logs

Additional info

This bug is not present in v28, but it is in v29, v30 and v31

[olive-spore-734]

It also happens when someone copies a file from a read only folder to a folder that was shared with them, but with every permission available. Running a files:scan fixes it (as mentioned in the duplicate) ...but not always.

[rotdrop]

Actually, this bug does not only affect shares but mounts in general. Copying out of read-only mounts -- be they shares or not -- will result in read-only destination files. I can also add to this that this is not a problem with the PHP internals of lib/private/Files/; copyFromStorage() when called directly will just create files with the default permissions of the destination storage (i.e. also writable).

How should web-dav behave here on a COPY request?

• should it generate a verbatim copy as much as possible, including permission?
  • if so, the web-frontend files_app needs to add further attributes to the COPY request in order to make the destination files writable (is that possible?)
• or should the WebDAV backend generate the destination files with most-allowable permissions?

Also: although in the backend individual files have their own permissions in NC, it is not possible to adjust those permissions through the web-frontend. This means: if something goes wrong -- like in the cases describe in this issue -- the user has no means to recover (ok, the user could download the files, delete the read-only copy on the server, then upload again. Supposedly that would work, but this is not an acceptable work-around).