Core: Cannot share top-level of read-only storage

[phil-davis]

Steps to reproduce

1. As an admin, in settings-admin-storage create some local storage that makes some folder on the local server available - e.g. local-folder
2. set "Available for" to some user "Anne" (or group that Anne is a member of)
3. select the "enable sharing" and "Set read-only" options
4. as user "Anne" try to share local-folder with "Bob"

Expected behaviour

The share should be created with just the allowed "read" permissions

Actual behaviour

Notification is displayed:

Cannot set the requested share permissions for local-folder

and the share is not created.

There is no way to get to the sharing permissions checkboxes and turn off "edit".

(note: it works fine when sharing a sub-folder or file inside local-folder. In that case, it "knows" to make the share read-only)

Server configuration

Current core master

The "Set read-only" option for storage was added by PR https://github.com/owncloud/core/pull/36397 and issue https://github.com/owncloud/core/issues/29873

[phil-davis]

A similar case is when Anne has received a share from someone and has "can share" permission and the received share is read-only.

When Anne tries to reshare the received share to Bob, the UI happily understands that the received share is read-only, and so it makes the reshare read-only also. Anne does not even see the not-allowed permission checkboxes for "can edit"...

I guess that in the read-only local-folder case, the UI is not aware that local-folder is read-only. Maybe there is some "easy" extra code in the backend that needs to know about the read-only setting of the storage and report it back to clients (like the UI)

[davitol]

AFAIK It has been always the behaviour implemented and we decided that 'was fine' in this way (cc @pmaier1 just maybe for more feedback)

[phil-davis]

This is a bit different new scenario. Local storage can now be explicitly set to read-only (regardless of the underlying storage file/folder permissions). So now "ordinary installs" can set local-storage to read-only. When they do that, there is this webUI problem (which maybe is something we "live with" or we fix)

[micbar]

@pmaier1 IMO we can leave that now

[phil-davis]

Moved this to QA/CI to make sure there is some acceptance test that demonstrates the behavior.

• [x] make webUI test scenario to demonstrate the behavior
• [x] make CLI test scenario to demonstrate the behavior

Tag the scenarios with this issue number.

Then someone can decide if the behavior needs to be changed.

[pmaier1]

This is a bit different new scenario. Local storage can now be explicitly set to read-only (regardless of the underlying storage file/folder permissions).

Can you share the top level if it's not set to read-only? To me it makes sense that only children can be shared as "sharing" the top level works via the actual external storage mount. Still, there should not be inconsistency with read-only.

[phil-davis]

Can you share the top level if it's not set to read-only?
Yes, you can share. Because the UI "defaults" to sharing with "edit" privs, those privs match what is allowed and so the share API request succeeds.

I guess that the use-case is where the is some local storage called department-data and it is mounted and made available to group department and with sharing allowed. Some user in department then tries to share with someone else that is not already in department group.

That should work appropriately whether the local storage has been mounted read-only or read-write.

[phil-davis]

Removed QA assignment. There are acceptance tests for this now. Fixing it can be scheduled.

Note: https://github.com/owncloud/files_primary_s3/issues/351 - there might be some different behavior happening with ceph/scality object storage. QA will investigate in that files_primary_s3 issue

[phil-davis]

This is working OK in files_primary_s3. See https://github.com/owncloud/files_primary_s3/pull/367 for the test scenario.