[Bug]: sharing permissions set via API are incorrect

[tfboy]

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

I had a similar issue with a previous version of NC, but thought I'd report it again with NC28.0.4
The problem is that despite defining explicit sharing permissions when creating a public share via curl and the API, these are ignored and the defaults are used.

Steps to reproduce

Create a share via curl. For example: curl -u user:pass -X POST 'https://nc.local/ocs/v2.php/apps/files_sharing/api/v1/shares?shareType=3&publicUpload=true&permissions=4&path=/Upload' -H "OCS-APIRequest: true"

Expected behavior

With the above, and having explicitly defined permissions=4, the share is created with the default "31" persmissions. Here's the output of the above:

<?xml version="1.0"?>
<ocs>
 <meta>
  <status>ok</status>
  <statuscode>200</statuscode>
  <message>OK</message>
 </meta>
 <data>
  <id>6</id>
  <share_type>3</share_type>
  <uid_owner>testuser</uid_owner>
  <displayname_owner>Test User</displayname_owner>
  <permissions>31</permissions>
  <can_edit>1</can_edit>
  <can_delete>1</can_delete>
  <stime>1712836212</stime>
  <parent/>
  <expiration/>
  <token>YLjaqDzfasRzNF4</token>
  <uid_file_owner>testuser</uid_file_owner>
  <note></note>
  <label></label>
  <displayname_file_owner>Test User</displayname_file_owner>
  <path>/Upload</path>
  <item_type>folder</item_type>
  <item_permissions>31</item_permissions>
  <mimetype>httpd/unix-directory</mimetype>
  <has_preview></has_preview>
  <storage_id>home::testuser</storage_id>
  <storage>3</storage>
  <item_source>410</item_source>
  <file_source>410</file_source>
  <file_parent>243</file_parent>
  <file_target>/Upload</file_target>
  <item_size>0</item_size>
  <item_mtime>1712834760</item_mtime>
  <share_with/>
  <share_with_displayname>(Shared link)</share_with_displayname>
  <password/>
  <send_password_by_talk></send_password_by_talk>
  <url>https://nc.local/index.php/s/YLjaqDzfasRzNF4</url>
  <mail_send>1</mail_send>
  <hide_download>0</hide_download>
  <attributes/>
 </data>
</ocs>

The share attributes are clearly defined as 31.
The produced link works, but of course provides all the sharing permissions and not what I explicitly requested - upload only / dropbox.

I can "fix" this by updating the share via a second API request but this really shouldn't be necessary if the permissions attribute is followed as described in the OCS Share API documentation.

Installation method

Community Manual installation with Archive

Nextcloud Server version

28

Operating system

RHEL/CentOS

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?

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": [
            "cdebox.francetelevisions.fr"
        ],
        "datadirectory": "***REMOVED SENSITIVE VALUE***",
        "dbtype": "mysql",
        "version": "28.0.4.1",
        "overwrite.cli.url": "https:\/\/nc.local",
        "dbname": "***REMOVED SENSITIVE VALUE***",
        "dbhost": "***REMOVED SENSITIVE VALUE***",
        "dbport": "",
        "dbtableprefix": "oc_",
        "mysql.utf8mb4": true,
        "dbuser": "***REMOVED SENSITIVE VALUE***",
        "dbpassword": "***REMOVED SENSITIVE VALUE***",
        "installed": true,
        "defaultapp": "files",
        "memcache.distributed": "\\OC\\Memcache\\Redis",
        "memcache.locking": "\\OC\\Memcache\\Redis",
        "memcache.local": "\\OC\\Memcache\\APCu",
        "maintenance_window_start": 1,
        "default_phone_region": "FR",
        "redis": {
            "host": "***REMOVED SENSITIVE VALUE***",
            "port": 6379
        }
    }
}

List of activated Apps

Enabled:
  - activity: 2.20.0
  - circles: 28.0.0
  - cloud_federation_api: 1.11.0
  - comments: 1.18.0
  - contactsinteraction: 1.9.0
  - dashboard: 7.8.0
  - dav: 1.29.1
  - federatedfilesharing: 1.18.0
  - federation: 1.18.0
  - files: 2.0.0
  - files_pdfviewer: 2.9.0
  - files_reminders: 1.1.0
  - files_sharing: 1.20.0
  - files_trashbin: 1.18.0
  - files_versions: 1.21.0
  - firstrunwizard: 2.17.0
  - logreader: 2.13.0
  - lookup_server_connector: 1.16.0
  - nextcloud_announcements: 1.17.0
  - notifications: 2.16.0
  - oauth2: 1.16.3
  - password_policy: 1.18.0
  - photos: 2.4.0
  - privacy: 1.12.0
  - provisioning_api: 1.18.0
  - recommendations: 2.0.0
  - related_resources: 1.3.0
  - serverinfo: 1.18.0
  - settings: 1.10.1
  - sharebymail: 1.18.0
  - support: 1.11.1
  - survey_client: 1.16.0
  - systemtags: 1.18.0
  - text: 3.9.1
  - theming: 2.3.0
  - twofactor_backupcodes: 1.17.0
  - updatenotification: 1.18.0
  - user_status: 1.8.1
  - viewer: 2.2.0
  - weather_status: 1.8.0
  - workflowengine: 2.10.0
Disabled:
  - admin_audit: 1.18.0
  - bruteforcesettings: 2.8.0
  - encryption: 2.16.0
  - files_external: 1.20.0
  - suspicious_login: 6.0.0
  - twofactor_totp: 10.0.0-beta.2
  - user_ldap: 1.19.0

Nextcloud Signing status

No errors have been found.

Nextcloud Logs

No response

Additional info

No response

[joshtrichards]

Related: #37774 & #17504

[susnux]

Create a share via curl. For example: curl -u user:pass -X POST 'https://nc.local/ocs/v2.php/apps/files_sharing/api/v1/shares?shareType=3&publicUpload=true&permissions=4&path=/Upload' -H "OCS-APIRequest: true"
With the above, and having explicitly defined permissions=4, the share is created with the default "31" persmissions. Here's the output of the above:

This is expected behavior because you have specified publicUpload=true.

So what you have set:

• permissions=4: Allow only creating files
• publicUpload: This is not recommended to set anymore. It is a legacy flag from very old times. What it does is overwriting the permissions to allow the full UI (permissions READ+MODIFY+DELETE).

So just remove the publicUpload param or set it to false.

---

But there is also a flaw in the API, if you only set "permissions=4" then READ will also always be granted.
This is tracked in issue #17504

Work around:
Update the share with permissions=4 after creating it, the update API works.

[tfboy]

@susnux , thanks for confirming.

I have a feeling I needed the publicUpload flag before otherwise it didn't work at all, but that was for v28 of NC. Clearly not the case now.

However, if the publicUpload is a very old and not recommended, may I suggest the official latest documentation states this. At the moment, there's no indication that's the case.