The security of a project or folder depends on the permissions that each group has on that resource. The default security settings are designed to meet common security needs, and you may find that they work for you and you don't need to change them. If you do need to change them, you'll need to understand how permissions settings work and what the different roles mean in terms of the kinds of access granted.
Security settings for a Studies provide further refinement on the folder-level permissions covered here, including the option for granular control over access to study datasets within the folder that will override folder permissions. See Manage Study Security for details.


A role is a named set of permissions that defines what members of a group can do. You secure a project or folder by specifying a role for each group defined for that resource. The privileges associated with the role are conferred on each member of the group. Assigning roles to groups is a good way to simplify keeping track of who has access to what resources, since you can manage group membership in one place.

Setting Permissions

To set permissions, you assign a role to a group or individual user.

Note: Before you can grant roles to users, you must first add the users at the site level. When you type into the "Select user or group..." box, it will narrow the pulldown menu to the matching already defined users, but you cannot add a new account from this page.

  • Select (Admin) > Folder > Permissions.
  • Set the scope of the role assignment by selecting the project/folder in the left-hand pane.
  • In the image below the Research Study subfolder is selected.
  • To grant a role, locate it in the Roles column and then select the user or group from the Select user or group... pulldown.
  • Click Save or Save and Finish to record any changes you make to permissions.

Revoke or Change Permissions

Permissions can be revoked by removing role assignments.

  • To revoke assignment to a role, click the x in the user or group box.
  • Here we will revoke the "Author" role for the group "Guests" as it was added by mistake.
  • You can also drag and drop users and groups from one role to another.
  • Dragging and dropping between roles removes the group from the source role and then adds it to the target role. If you want to end up with both roles assigned, you would need to add to the second group instead.

Inherit Permission Settings

You can control whether a folder inherits permission settings, i.e. role assignments, from its immediate parent.

  • Check the checkbox Inherit permissions from parent, as shown below.
  • When permissions are inherited, the permissions UI is grayed out and the folder appears with an asterisk in the hierarchy panel.

Site-Level Roles

A few specific permissions are available at the site level, allowing admins to assign access to certain features to users who are not full administrators. For a listing and details about these roles, see the Security Roles Reference documentation

To configure site-level roles:

  • Select (Admin) > Site > Site Permissions.

Permission Rules

The key things to remember about configuring permissions are:

Permissions are additive. This means that if a user belongs to several groups, they will have the superset of the highest level of permissions granted by all groups they are in.

Additive permissions can get tricky when you are restricting access for one group. Consider whether other groups also have the correct permissions. For example, if you remove permissions for the ProjectX group, but the Users (logged-in-site users) group has read permissions, then Project X team members will also have read permissions when they are signed in.

In a study, the exception to this pattern is that dataset-level permissions are not additive but will override folder-level permissions for datasets.

Folders can inherit permissions. In general, only site admins automatically receive permissions to access newly-created folders. However, default permissions settings have one exception. In the case where the folder admin is not a project or site admin, permissions are inherited from the parent project/folder. This avoids locking the folder creator out of his/her own new folder.

Visibility of parent folders. If a user can read information in a subfolder, but has no read access to the parent, the name of the parent container will still appear on the folder menu and in the breadcrumb path, but it will not be a clickable navigation link.

Permissions Review Enforcement (Premium Feature)

It is good practice to periodically review project permissions to ensure that the access is always correct. Setting reminders and defining policies outside the system are recommended.

Premium Features Available

Subscribers to the Enterprise Edition of LabKey Server can use the compliance module to enable an automated Project Review Workflow to assist project managers. Learn more in this topic:

Learn more about premium editions

Related Topics

Was this content helpful?

Log in or register an account to provide feedback

expand allcollapse all