1. Support Center
  2. FAQ
  3. Best Practices/General Use

Are there any best practices around managing permissions on my Platform Spaces?

Permissions management is generally straight-forward, however if you have a large number of users and platform spaces, there are a few things to keep in mind when processing large batches of permissions changes.

Common Permissions Operations

Common Permissions operations are defined as permissions affecting 10 or less users or Platform Spaces at the same time. This is traditionally "upkeep" permissions work that's done when new users are added to a project or a new project is added for a small (<10 user) workgroup. These operations are typically extremely fast to apply and require little consideration for performance when executing.

For example, on a Platform 1000 system (these systems have the highest single-core clock speed in the Platform lineup, resulting in the fastest permissions operations, note that all other systems will be slower to some degree) changing permissions on a single user to a single Platform space with 33K files takes approximately 10 seconds. Even when the disk system is under heavy use, this timing is not noticeably affected.

Common Platform Permissions Operations Best Practices and Notes

  • Platform honors both individual and group permissions. Using Group permissions dramatically reduces permissions operation time.
  • A User must be added to the Platform GUI user list if they need to access the Platform Web Interface, even if they obtain all of their permissions from group memberships.
  • When a user is added to or removed from a Platform Space, the system must "touch" every file on that space to propagate the new permissions.
  • During permissions operations, the file count of a platform space dictates the time needed to fully propagate the new permissions rather than the file size on disk. For example, a space that's 1TB in size containing 1 million files will take longer to apply permissions than a space that's 10TB and contains 1000 files.
  • Permissions operations use disk bandwidth when in progress. Normally, the hit to bandwidth is very small and often unnoticeable, however during bulk permissions changes you may experience a reduced disk access times for normal read/write operations.
  • Note that a single user change being propagated to a Platform space of 1 million files will take approximately 5 minutes in favorable disk conditions. Even common operations to large file count spaces can take a measurable amount of time. Knowing file count is key.

Bulk Permissions Operations

Bulk Permissions operations are defined as permissions changes affecting more than 10 users or Platform Spaces at the same time. This is common in larger workgroups during project creation or wrap-up where large numbers of users may be brought in or removed from a project, or during initial ingest and setup of large amounts of spaces.

Bulk changes require consideration of performance and timing to execute in a timely manner. For example, if you are attempting to change the permissions of 100 users on a group of Platform Spaces that total 1 million files, this operation would take approximately 8.5 hours if there are no other disk system activity occurring at the time. Additional disk activity during this period (normal editing bandwidth, mirrors, copies, LTO operations, etc) can extend this time significantly. Additionally, transcode activity can also adversely affect timing if the CPU is under heavy use during a bulk permissions update.

Bulk Permissions Best Practices

In addition to the best practices and notes from common operations, below are additional notes and practices that apply to bulk operations:

  • Bulk permissions changes can result in a permissions change operation taking an extended period of time to apply, so consideration must be made when changing permissions for more than a few users/spaces at a time.
  • If you have significant file operations in progress on the disk system (Heavy read/write to clients, mirrors, copies, LTO operations) bulk permissions changes will take longer to process as they will share disk time with those operations.
  • Changes on hundreds of users against millions of files can take more than a day to process under ideal disk conditions.
  • It's recommended that non-essential file operations be suspended during significant bulk permissions changes. This includes extremely heavy editing bandwidth, running mirrors, scheduled copies, and scheduled LTO operations.
  • In versions prior to 5.6, there is a known bug with the permissions task progress bar that will cause it to stick at 0% until the entire permissions task is completed, at which point it will immediately jump to 100% and complete. This may incorrectly present an impression of inaction during a large bulk operation.
  • In versions after 5.6, the progress bar will update in chunks of 10 users and/or 10 spaces. If 100 users are given access to a single space, the bar will update to 10% after the first 10 users have had their permissions applied. If 100 users are given access to 20 spaces, the bar will update to 5% after the first 10 users have had their permissions applied to the first 10 spaces. The bar will then update to 10% when the same first 10 users have had their permissions applied to the remaining 10 spaces.

Special note on Permissions when Deleting and Removing Platform Spaces

For security reasons, deleting or removing a Platform Space from the system will trigger a permissions removal task prior to the delete/remove operation occurring. If you are deleting/removing a large space with many files and many users have access, the same rules apply to this kind of operation as a permissions change.

For example, if you are deleting/removing a Platform Space available to 20 users that has 100K files in it, the operation will take approximately 10 minutes of permissions changes before the delete/removal process itself begins.