Delete file sharing custom permission disabled (grayed out)

ℹ️ Support
, , , ,
1

The Basics

  • Nextcloud Server version (e.g., 29.x.x):
    • Nextcloud Hub 10 (31.0.2)
  • Operating system and version (e.g., Ubuntu 24.04):
    • Ubuntu 24.04.2 LTS
  • Web server and version (e.g, Apache 2.4.25):
    • Apache/2.4.58 (Ubuntu)
  • Reverse proxy and version _(e.g. nginx 1.27.2)
    • None
  • PHP version (e.g, 8.3):
    • PHP 8.3.6
  • Is this the first time you’ve seen this error? (Yes / No):
    • Yes
  • When did this problem seem to first start?
    • Since initial install.
  • Installation method (e.g. AlO, NCP, Bare Metal/Archive, etc.)
    • Archive
  • Are you using CloudfIare, mod_security, or similar? (Yes / No)
    • No

Summary of the issue:

Delete permission option disabled (grayed/greyed out) when setting up individual user directed file sharing. Unable to select. (Note: This is specific to files, folders/directories do not have this issue)

image
image478×454 18.8 KB

Appears to be independent of web browser.

Nextcloud

{
“system”: {
“instanceid”: “REMOVED SENSITIVE VALUE”,
“passwordsalt”: “REMOVED SENSITIVE VALUE”,
“secret”: “REMOVED SENSITIVE VALUE”,
“trusted_domains”: [
“REMOVED SENSITIVE VALUE”,
“REMOVED SENSITIVE VALUE”,
“REMOVED SENSITIVE VALUE”
],
“datadirectory”: “REMOVED SENSITIVE VALUE”,
“dbtype”: “mysql”,
“version”: “31.0.2.1”,
“overwrite.cli.url”: “REMOVED SENSITIVE VALUE”,
“dbname”: “REMOVED SENSITIVE VALUE”,
“dbhost”: “REMOVED SENSITIVE VALUE”,
“dbport”: “”,
“dbtableprefix”: “oc_”,
“mysql.utf8mb4”: true,
“dbuser”: “REMOVED SENSITIVE VALUE”,
“dbpassword”: “REMOVED SENSITIVE VALUE”,
“installed”: true,
“maintenance”: false,
“maintenance_window_start”: 1,
“opcache.interned_strings_buffer”: 10,
“memcache.locking”: “\OC\Memcache\Redis”,
“memcache.distributed”: “\OC\Memcache\Redis”,
“memcache.local”: “\OC\Memcache\Redis”,
“redis”: {
“host”: “REMOVED SENSITIVE VALUE”,
“port”: “REMOVED SENSITIVE VALUE”,
},
“mail_smtpmode”: “smtp”,
“mail_smtpsecure”: “ssl”,
“mail_sendmailmode”: “smtp”,
“mail_domain”: “REMOVED SENSITIVE VALUE”,
“mail_from_address”: “REMOVED SENSITIVE VALUE”,
“mail_smtpauth”: true,
“mail_smtphost”: “REMOVED SENSITIVE VALUE”,
“mail_smtpport”: “465”,
“mail_smtpname”: “REMOVED SENSITIVE VALUE”,
“mail_smtppassword”: “REMOVED SENSITIVE VALUE”,
“skeletondirectory”: “”,
“htaccess.RewriteBase”: “/nextcloud”,
“theme”: “”,
“loglevel”: 2
}
}

Apps

Enabled:

  • activity: 4.0.0
  • app_api: 5.0.2
  • bruteforcesettings: 4.0.0
  • circles: 31.0.0
  • cloud_federation_api: 1.14.0
  • comments: 1.21.0
  • contactsinteraction: 1.12.0
  • dashboard: 7.11.0
  • dav: 1.33.0
  • drop_account: 2.7.1
  • encryption: 2.19.0
  • federatedfilesharing: 1.21.0
  • federation: 1.21.0
  • files: 2.3.1
  • files_downloadlimit: 4.0.0
  • files_pdfviewer: 4.0.0
  • files_reminders: 1.4.0
  • files_sharing: 1.23.1
  • files_trashbin: 1.21.0
  • files_versions: 1.24.0
  • firstrunwizard: 4.0.0
  • groupfolders: 19.0.4
  • logreader: 4.0.0
  • lookup_server_connector: 1.19.0
  • nextcloud_announcements: 3.0.0
  • notifications: 4.0.0
  • oauth2: 1.19.1
  • password_policy: 3.0.0
  • photos: 4.0.0-dev.1
  • privacy: 3.0.0
  • profile: 1.0.0
  • provisioning_api: 1.21.0
  • recommendations: 4.0.0
  • related_resources: 2.0.0
  • serverinfo: 3.0.0
  • settings: 1.14.0
  • sharebymail: 1.21.0
  • support: 3.0.0
  • survey_client: 3.0.0
  • systemtags: 1.21.1
  • terms_of_service: 4.3.0
  • text: 5.0.0
  • theming: 2.6.1
  • twofactor_backupcodes: 1.20.0
  • twofactor_totp: 13.0.0-dev.0
  • updatenotification: 1.21.0
  • user_status: 1.11.0
  • viewer: 4.0.0
  • weather_status: 1.11.0
  • webhook_listeners: 1.2.0
  • workflowengine: 2.13.0
    Disabled:
  • admin_audit: 1.21.0
  • files_external: 1.23.0
  • suspicious_login: 9.0.1
  • twofactor_nextcloud_notification: 5.0.0
  • user_ldap: 1.22.0
2

One spontanous idea, could it be possible that the “delete” option has been unticked under the Admin sharing setting?

3

Could be. I may have missed it, but it appears to me the system administration setting for sharing wouldn’t interfere.

image
image1129×1493 105 KB

4

To be on the save side you can check if the “Default share permissions” will have an impact on the seen behavior.

5

Yes, a good diagnostic technique.

Setting (checking) a default share permission of delete, does result in delete being visually selected when saving a share setting for a file initially. But when one goes back to check the share setting on the file, delete is no longer checked/set. Additionally the user the file is shared with does not have a delete option in their drop down menu for the file, and thus is unable to delete.

Effect only seems to be skin deep and even then is transitory for a file.

Suggesting it is likely not a GUI issue but more of a backend issue.

6

Have re-installed nextcloud with minimal configuration changes and no apps added from the default install. The issue is the same. Running Nextcloud Hub 10 (31.0.5) in this case.

7

Is the account setting up this new share the original owner of the file? Or are they resharing it?

8

Original owner.

9

Should be noted that folders don’t exhibit this issue. Ability to share a folder while granting delete permission is available (ie the delete permission is not grayed out in this case and this capability is functional).

10

I did notice that with a shared folder [where delete permission is granted on the folder], one is able to delete the files within the folder but not the folder itself.

In this sense it follows standard file system permissions where if one is given write access to a directory, they are able to delete files and directories within that directory, but not the directory itself.

Following a standard file system, one would never be able to give delete privileges just to a file itself. One would need to give write access to the directory containing the file.

So maybe this is by design. Just surprised no documentation supporting this [that I was able to find], and that no one has jumped in to say more or less the same.

11

I tried one of the service providers at Nextcloud partners and with sharing a link for external users (slightly different use case), the results were the same. That is for a folder/directory delete permission is permitted as part of the share, whereas for a file (ie non-special file, as opposed to a directory which is considered a special file at least under unix), delete permission was not permitted as part of the share, that is delete was disabled as an option.

Again this is leading me to believe this is by design.

Will put this aside for the time being. If nothing comes up to indicate otherwise I will close with that solution.

12

ShareAPIController.php has the comment:

For some reason, single files share are forbidden to have the delete permission

which further indicate this is by design, provided the context is the same. The reasoning must be apparent elsewhere.

I’m still perplexed that I’m not seeing any documentation to support this nor that no one else is observing or commenting on this behavior. Also it’s unclear why the delete option would be grayed out, and not just removed entirely.

Perhaps it’s just obvious the delete option wouldn’t be available for a regular file for the reason I previously stated, though the code comment above suggests otherwise.

Will hold off a little longer. Would like to discover something more definitive.

13

I have got the same problem. But i never need the possiblity to delete one shared file. But i think it is a bug. There is also the issue #52954. I have got the problem on a fresh installed Nextcloud 31.0.6.

1 Like
14

Good to know @devnull. Thanks.

So your thought is that it’s a feature not often utilized, thus most users are unaware of it being an issue, and thus it’s only recently it was reported as a bug.

It would be interesting to install earlier versions of nextcloud to see if the “bug” was there from the start or if was introduced at a later point in time.

What do you make of the comment in ShareAPIController.php that I referenced? Does that apply to a different context?

15

Anyone running say Nextcloud Server version v30.0.0 or earlier that could see if the same behavior exists there? The code comment I referenced earlier I believe was from v31.0.0beta1 for what it is worth.

Also there is * Fix(files_sharing): Prevent create/delete permissions on file shares (server#52530) from stable30 that again suggests this is expected behavior.

logger.debug(‘Removed create/delete permissions from file share (only valid for folders)’)