Fine-Grain Folder permissions : invisible

Good idea. But this could make problems if syncing those folders on the file system side with the client.

If you don’t want others to access the top level shared folder by default, you can just share the sub-folders under it to specific users/groups. Allowing “inaccessible” permission in the default share seems unnecessary to me.

I think both invisible and inaccessible permissions have their own use cases. In some cases the share owner just don’t want some users to know there is such a sub-folder. But it looks over complex and confusing to allow users to choose both permissions. So we’ll go for the invisible way first and see how users react.

i understand your concern.
if there is a invisible option, which works similar to folder permssions with READ or READ-WRITE permissions, it should work for us.

would this work:

  1. Share Library to a group as READ.
  2. via API set folder permissions for Project A/Marketing, Project A/ProjectPlanning, Project A/Meetings, Project A/Management-Only,… to INVISIBLE. Therefore leaving only Costs and Sales untouched.

The group should be able to sync just Project A/Costs, Project A/Sales then. Is this correct?

1 Like

I understand you ideas. But your proposed model doesn’t quite fit with Seafile’s design. It could be quite tricky to implement. We’ll take this into account but no promise it’ll be 100% what you want…

I don’t think this kind of usage can be satisfied even in Windows network share.

In your description, if Projects is shared as invisible while “Project A/Costs” is set to visible. There is no easy way to determine whether the folder list (“Project A, Project B, …”) in Projects and folder list in “Projects/Project A” can be visited by a user.

When you share Projects to a user as invisible, the user should not be able to see the folder list in Projects. Later, you set “Project A/Costs” to be visible to the user. Then the user will be able to see the folder list in Projects, otherwise the user can’t navigate to “Project A/Costs”. This makes the system has to check whether there is a sub-folder or sub-sub-sub-folder in a folder set to visible before determining whether the current folder is visible the user, which is quite complicated.

After thinking it for a while and looking into other systems, I propose a simple solution, that is you can set a share name when share a folder. So you can share project A/costs, project B/costs to the account team as project A-costs, project B-costs.

In this way, the accounts can access to the folders without confusion and the desktop clients can be used.

Ok, and this will look like sub-libraries to the clients or how can we imagine this? I just think of having twenty or hundreds of sub-folders and i want to manage them easily. Maybe i didn’t understand your idea, can you describe it a litte bit more for us?

Yes, this is like sub-libraries. But the folder admin can set the name seen by the be-shared. At least, the accounts don’t see tens of folders with the same name ‘costs’.

Hi Daniel,

I am sorry, that is not really what we asked for.

Almost any filesystem used on client-side uses a hierarchy, even seafile based libraries.
Your suggestion strips away the hierarchy. We wanted to restricted access, as in “fine-grained” permission on sub-directory level.

Your suggestion would generate a flat view on our document structure, loosing any project/department information. Having them all renamed on a flat hierarchy, causes our employees to scroll down 100 or more libraries, to find the e.g “costs” folder for departmentA/projectG/costs.

I liked the previous invisible approach of yours better. Your latest approach however would be unusable for this use case.

best regards,
Philip

Hi,

What’s the status of the new “invisible” permission you mentioned a few months ago?
I would be very interested in using it to restrict access to some sub-folders while still sharing the whole library.

Thanks for your help.

We have cancelled the plan to add invisible permission. It turned out to be very difficult to implement when syncing is involved.

1 Like

What if it followed the ABE service like in Windows Server? Where maybe the emphasis isn’t that the share is invisible, but skipped over due to not having permission and thus looks like it is invisible to the user? (just bumped into a case where we need a shared library, but a folder in there is meant to only be seen by a couple of people instead of the entire team)

sad
Nextcloud has it implemented - you can set Tags on any folder or file and based on rules, users or groups simply have access or not. The Desktop client then simply does not sync these files/folders as it can not access them.
I’d love to see read-only / read-write / no-access settings for at least folders.

The problem arises if a content was accessible and synced in the past and suddenly not anymore.
But I think this can be solved in the same manner as what I’ve seen in Nextcloud and documented here.
https://forum.seafile.com/t/seafile-client-not-showing-warning-error-when-syncing-with-read-only-library-folder/8824/3

Having a very clear notification to the user if a content can not be synced (for different reasons, access rights, etc) would help the user to see if all is working (100% synced) or if he needs to take action.

I have a similar question about “no-access” but within Departments.
As soon as I add a user to a department, he gets full access to all Libraries within this department.
Is there a way to block access to certain libraries for certain users in a Department?

What I did as a workaround: add only the admin to the Department and then use old-school sharing of individual Libraries to users. But I guess this is not the purpose of Departments…

No such way. The purpose of department library is to be shared to the whole department.

Is there any news regarding this topic?
I am looking for a solution to a similar issue:

We are using a library called “Events” to store and sync media files related to specific events.
Some computers which are synchronizing the “Events” library should not have access to all events, but only the ones which are explicitly shared with their restricted user.

As I understand, there are two options currently available:

  1. Share the whole library read-only and grant write permissions for the specific events. This would however also give access to all the other event data, which should not be accessible on the restricted computers.
  2. Share the individual sub-folders. However this will not automatically sync new folders on the restricted computers and cause a flat folder hierarchy in the restricted user account.

Do you have any suggestion for my issue?

Thanks in advance
Michael

You can share the whole library read-only and grant write permissions for the specific events. Then use the drive client to only sync files that used.

But this is what needs to be avoided: the restricted computers should only have access to the folders which they should sync.
Synchronisation of new folders should happen automatically then, without the need of configuring each computer individually.

You can create an account for that computer, and only share folders to this account that this computer need to access.

I agree that this should be a standard way of working. In my line of work, it’s very important to keep the file structure of folders, so it would be a great option to be able to share a library with a group, but then be able to control the visibility to individual folders, not only read-write access.

1 Like