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

Receiver of a share from a external mount point cannot see the shared files #28564

Closed
jvillafanez opened this issue Aug 2, 2017 · 10 comments
Closed

Comments

@jvillafanez
Copy link
Member

Steps to reproduce

  1. Setup an admin mount point with a specific configuration, only for the admin. Make sure sharing is enabled for the mount point
  2. Setup the same mount point as personal for the admin. The mount point configuration must be the same as the admin one. Sharing must be disabled for this mount
  3. Share a file from the mount point to another user
  4. Login with the other user's account

Expected behaviour

Shared file should show up

Actual behaviour

Shared file is missing. The user account can't access to the shared file.

Server configuration

Operating system: ubuntu 16.04

Web server: apache 2.4.7

Database: mysql

PHP version: 7.0

ownCloud version: master (Aug, 2th 721b36d)

Updated from an older ownCloud or fresh install: fresh install

Are you using external storage, if yes which one: reproducible with any external storage

Are you using encryption: no

As a workaround, you'll need to enabled / disable sharing for both mounts.

@DeepDiver1975 @PVince81

@PVince81
Copy link
Contributor

PVince81 commented Aug 2, 2017

Hmm, could it be related to the fact that they both share the same storage string id ? But they should be different mount entries in the mount config tables.

@hodyroff
Copy link
Contributor

hodyroff commented Aug 3, 2017

One mount point should only be possible for one owner/user one time. For me, for now its sufficient to document that, if easy or when this is hit by users/customers we maybe need to forbid it. Or is there a good user story why somebody would want to do that?

@PVince81
Copy link
Contributor

PVince81 commented Aug 3, 2017

@hodyroff currently system-wide mount points can be assigned to multiple users/groups (field "applicable") by an admin. Such mount points can only be created by admins. So this is a supported case.

Now with the case above, I think the proper way would be that the admin adds the user in the "applicable" field to give the user access to that share instead of letting the user add a new mount for themselves.

@jvillafanez
Copy link
Member Author

It seems the admin configuration is overlapped with the personal one, so what is used is whatever the personal configuration has. Since the personal configuration had the sharing disabled that would explain why the shared files are missing.
If we switch the sharing configuration so the personal mount has sharing enabled but the admin mount has it disabled, the personal mount will take precedence, so sharing will be enabled and the shared files will appear.

I think this mount overlapping has been discussed already. This seems another issue caused by that mount overlapping.

@PVince81
Copy link
Contributor

PVince81 commented Aug 4, 2017

Ah, it wasn't clear to me that both mounts use the exact same mount point name... This is not good practice... and also an unsolvable bug (unsolvable without tearing up a hole in this messy mount system): #10511

I'd close this in favor of #10511 then...

@PVince81 PVince81 closed this as completed Aug 4, 2017
@jvillafanez
Copy link
Member Author

Ah, it wasn't clear to me that both mounts use the exact same mount point name...

The mount point name is different, but the configuration is the same in both.

@PVince81
Copy link
Contributor

PVince81 commented Aug 4, 2017

Ok then it's a different issue. The end user should see both mount points, one with sharing enabled and one without

@PVince81 PVince81 reopened this Aug 4, 2017
@davitol
Copy link
Contributor

davitol commented Sep 13, 2017

Due to it is not a very common configuration let's set a lower priority

@ownclouders
Copy link
Contributor

Hey, this issue has been closed because the label status/STALE is set and there were no updates for 7 days. Feel free to reopen this issue if you deem it appropriate.

@felixboehm felixboehm removed this from the triage milestone Apr 10, 2018
@lock
Copy link

lock bot commented Jul 30, 2019

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.

@lock lock bot locked as resolved and limited conversation to collaborators Jul 30, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

6 participants