Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Cannot share top-level of read-only storage #36803

Closed
phil-davis opened this issue Jan 22, 2020 · 11 comments
Closed

Cannot share top-level of read-only storage #36803

phil-davis opened this issue Jan 22, 2020 · 11 comments

Comments

@phil-davis
Copy link
Contributor

phil-davis commented Jan 22, 2020

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 #36397 and issue #29873

@phil-davis
Copy link
Contributor Author

phil-davis commented Jan 22, 2020

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)

@phil-davis phil-davis changed the title Cannot share read-only storage Cannot share top-level of read-only storage Jan 22, 2020
@davitol
Copy link
Contributor

davitol commented Jan 27, 2020

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
Copy link
Contributor Author

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
Copy link
Contributor

micbar commented Feb 20, 2020

@pmaier1 IMO we can leave that now

@phil-davis
Copy link
Contributor Author

phil-davis commented Apr 15, 2020

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

  • make webUI test scenario to demonstrate the behavior
  • 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
Copy link
Contributor

pmaier1 commented Apr 15, 2020

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
Copy link
Contributor Author

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
Copy link
Contributor Author

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

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

@phil-davis
Copy link
Contributor Author

This is working OK in files_primary_s3. See owncloud/files_primary_s3#367 for the test scenario.

@stale
Copy link

stale bot commented Sep 19, 2021

This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 10 days if no further activity occurs. Thank you for your contributions.

@stale stale bot added the status/STALE label Sep 19, 2021
@stale
Copy link

stale bot commented Sep 20, 2021

This issue has been automatically closed.

@stale stale bot closed this as completed Sep 20, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants