Folder Permissions

Folder permissions define what an account can do with files. They also determine who may establish shared access or configure workflows over those files. An access review therefore needs to distinguish the person's current permissions from the resources created using those permissions.

Effective Access

For ordinary users, direct grants and group grants add together. Removing one grant does not remove access that another grant still supplies. Recursive permissions extend to subfolders; permissions limited to one folder do not. The Check Access feature shows the effective access for a user, group, or Partner at a particular folder, including where that access comes from.

Use groups to maintain a shared set of permissions for a team. Review membership as part of the permission decision: adding someone to a group gives them the access already assigned to it. A Group Admin who can manage membership can make that decision without editing the folder's permission list.

Partner Users follow their Partner's permissions and Root Folder instead. Site Administrators and Workspace Administrators retain their administrative authority; ordinary folder grants do not restrict that authority.

Routes and Other Sites

A Partner Channel Route Path checks the requester at the Channel path, without requiring a separate grant on the same Site's target. A Parent Site Administrator has full access to Child Site files through _/Sites/<child-site-id>. A Connected Site checks both Guest-side access and the Host Partner's permissions for every operation. Partners cannot hold Share permission, so a Guest cannot share Host files through a Share Link, including when the Guest user is a Site Administrator. A Files.com Remote Server additionally checks the paired API key on the other Site. Including files from its mount in a Share Link requires Share permission from both the creator and the paired key on their respective Sites. Listings, counts, and sizes include only content allowed by every applicable check. Access Across Sites and Storage explains how those checks combine with settings and History.

Path Matching on Mounted Storage

An access review of a Remote Server Mount must account for Files.com's path comparison rules. Folder permissions match paths the same way on native and mounted storage. A remote system may preserve separate entries whose names differ only in case, accents, or other Unicode characters that Files.com treats as equal; a grant applies to every matching location. Its permission level and subfolder scope still determine the allowed actions.

Separate remote entries therefore do not necessarily have separate Files.com permissions. Use names that compare differently when they need independent access rules. API key path restrictions use the same comparison and cannot separate those equivalent names either.

What Each Level Permits

Read permission includes downloading. List/Preview permits viewing supported content without ordinary download access, but a person can still capture or copy what a preview displays. List permission exposes names and metadata without file contents. Choose these permissions based on what the recipient may learn, as well as which buttons they should use.

Write permission supports delivery of new files. Full permission also permits general replacement, moves, renames, and deletion. Write and Read/Write include limited upload replacement allowances so clients can complete or resume uploads without receiving general Full permission. A workflow that requires an immutable submitted record should move completed submissions into an appropriately controlled location rather than assume Write means a path can never be written again.

Share permission lets someone establish a separate route for recipients to access content. Folder Admin adds administration over permissions, folder settings, notifications, and v1 Automations. These powers go beyond reading or writing the folder: they can change how other people receive its files or information about its activity.

Folder Administration and Directory Visibility

Folder Admins control permissions, supported folder settings, notifications, and v1 Automations for the folders they administer. They can see all users and groups on the site, including people and groups that have no access to those folders. This directory visibility is intentional: an administrator must be able to find the people and groups to whom they want to grant access or assign notifications.

A folder's permission list is not a filter on the user and group directory. Grant Folder Admin access only to someone who may see that directory. Seeing an account or group does not itself grant permission to edit it, change its membership, or read its files elsewhere. Those actions require their own permissions.

Ancestor visibility depends on recursion. For permission records, Folder Settings, and notifications, a record on an ancestor folder, including the site root, is visible through a descendant only when it is recursive and its scope reaches a folder the Folder Admin administers. Non-recursive records and records whose scope does not reach those folders are not included through ancestor visibility. This lets Folder Admins understand inherited access and rules affecting their folders.

Folder Admins can see permission records on their administered folders and all subfolders, plus ancestor grants that meet this recursion requirement. The records include permissions assigned to other users, groups, or Partners. Seeing an ancestor's grants does not grant access to that ancestor's files or permission to change its grants. Permission records on sibling folders and unrelated branches remain outside the Folder Admin permission's scope unless the user also administers those folders.

The REST API's GET /permissions list follows the same administrative scope and recursion requirement. Supplying path narrows the result to grants that apply to that folder, including permissions inherited from above it. The web app's Permissions tab uses this folder-specific view and lists inherited grants under Inherited. Site Administrators can see every permission on the site.

Inheritance and Permission Fences

Files.com uses additive permissions rather than negative grants. A Permission Fence stops permissions inherited from above a folder, allowing new grants inside that subtree. Fences are intended for migrations from systems with deny rules; a straightforward folder and group design is easier to maintain for new deployments.

A Permission Fence moves with its folder, including a move into a Remote Server Mount. It continues to block inherited permissions at the folder's new path, so moving the folder does not make its contents available through the new parent's grants.

A fence also excludes that subtree from a parent folder's Share Link or Public Hosting configuration. It does not restrict Site Administrators, remove Folder Admin authority, or stop a permitted deletion of the parent folder from deleting the subtree with it. Notifications configured above the fence can still report activity below it when they are recursive. A fence is an inheritance control, not a separate administrative, retention, or notification boundary.

A fence does not guarantee that the folder's name stays private. Users without access inside it do not see it in the parent's listing, but a user who can write to the parent can infer that a name is in use if a matching creation is refused or an upload is renamed to avoid a conflict. If the name itself is sensitive, place the folder under a parent those users cannot write to.

Granting a broader permission can replace redundant narrower grants. Removing that broader permission later does not restore the grants it replaced. Review the resulting permissions rather than treating removal as an automatic return to the earlier configuration.

Shared Resources After Permission Changes

A Share Link has its own access rules and lifetime. Removing its creator's folder permission does not revoke it; a live link continues to expose the included paths as their contents change. This lets a business's external sharing continue when a staff member changes roles. Revoke the link separately when the intended outcome is to end recipient access.

Email notifications can also continue after a user's folder access is removed. Administrators can deliberately send activity notices to someone responsible for a process without granting that person file access. To end those notices, delete the notification or have the recipient unsubscribe. A permission review should include who receives activity information, not only who can open files.

Automations have their own ownership and execution permissions. A change to a user-owned v1 workflow's owner can affect its ability to run; site-owned and Workspace-owned workflows have a different lifecycle. Do not infer a workflow's access solely from the person who starts it.

Content Already Opened or Delivered

Removing a user's editing permission prevents further saves under that user's identity, even if the editor stays open. In a co-authoring session, the combined document is saved using the first participant's identity, so removing a different participant's access does not stop saves while that first participant remains authorized.

Previously loaded previews, editor contents, and downloaded copies may remain with the person who received them. Temporary download URLs also have their own expiration. Permission changes govern further authorized use of Files.com; they do not erase information already delivered.