Fine-Grain Folder permissions : invisible


I’m looking for a way to restrict folder permissions into a group to certain users.
This feature (Pro 5.1.4) could do the job :

But i’d like another right level : no permission (below read), that makes the folder invisible (and inacessible) to the user or the group selected.

Does it have any sense to you ?


This feature is in our schedule already. We’ll start work on it within a few months.

We are planing on migrating our data to a seafile installation.
Unfortunately fine-grained / ACL like permissions are an absolute MUST-HAVE for corporate data.

Can you give me a confirmation for the 6.1 milestone for this feature?
Also can you give me some details on the planned “design”?

This information is vital for our purchase plans.

Thank you,
best regards,

The feature is planed to be added in 6.1. We’ve finished some work.
You will have a new “invisible” permission along side the current read-only and write permissions. You can set this permission to a sub-folder under a shared folder, for a person or a group. The person or group cannot see this sub-folder, but other files or sub-folders are unaffected.


I have a use case where a certain group should only access a subset of the libraries top-level folders.
Is it possible to share a library “invisible”/inaccessible and grant explicit access to some folders?

Maybe it would be a good idea to call it “inaccessible”.
On sharing a library you select the default-behaviour for folder permssions in that “share”. e.g inaccessible, read, read-write. Then I would be able to set read or read-write to certain folders, since default is inaccessible. It is not a problem if everyone sees those folders, they should just be inaccessible.

Completely hiding those folders would possibly also cause confusion. The standard paradigm in this case is to see inaccessible folders and present a message of “missing” access permissions. Therefore someone could request access.

What do you think?

Hi @Philip_Konighofer,
I could vote for this solution, except that some users may be confused of seeing a folder they do not have access to and may complain about it ("tell my why i don’t have the right to access this ??!!!)

Imagine this: Another team member tells you the path to a folder. You “just” don’t see it, you would assume a failure/corruption in seafile or a selective sync issue. If it IS there and tells you don’t have access, you know what is going on!

1 Like

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,


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)

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.

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.