Folder permissions define which file operations a user, Group, or Partner may perform at a folder. They can allow someone to list names, read contents, upload files, change existing files, or share them with others. Choose grants for the information and actions the recipient needs, including whether the access extends to subfolders.

Effective Access

Files.com permissions are additive: each applicable grant supplies access, and a smaller grant does not cancel a broader one. Files.com does not support negative permissions or explicit deny grants. To remove an action, remove or change every grant that supplies it, rather than adding a more restrictive grant.

A user's direct permissions combine with permissions received through Groups. For example, if a Group grants Full permission on a folder, assigning Read permission directly to one member does not stop that user from changing or deleting files there. Removing the direct Read grant also leaves the Group's Full permission in place. Read and Write grants can combine to provide Read/Write access, but do not by themselves provide Full permission's general replacement, rename, move, and delete capabilities.

Use Groups to maintain shared grants for a team. Membership is part of the access decision: adding someone to a Group gives them its existing access. A Group Admin who can manage membership can make that decision without editing the folder's permission list.

Partner Users receive their Partner's folder permissions and remain within its Root Folder. They cannot join Groups or receive individual folder grants. Multiple grants to the Partner add together within that boundary. Site Administrators and Workspace Administrators retain their administrative authority; smaller folder grants do not restrict it.

Recursive permissions extend to subfolders; permissions limited to one folder do not. A Permission Fence can stop grants inherited from above its boundary. It changes which grants apply, rather than adding a deny grant. The Check Access feature shows effective access for a user, Group, or Partner, including its sources and inheritance boundaries.

Additive grants do not override independent controls. An API key can have a narrower path restriction than its user, another Site can require its own authorization, and protected content can prohibit changes. Review the applicable credential and resource controls alongside folder permissions.

What Each Level Permits

Names, Previews, and Downloads

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.

Uploads and Changes to Existing Files

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.

History permission allows review of file activity and creation of personal activity notifications. Share permission lets someone establish a separate route for recipients to access content. These are distinct capabilities to consider alongside file reads and writes; Full permission does not include every administrative or sharing capability.

Folder Admin includes all folder permissions and administration over grants, supported Folder Settings, notifications, and v1 Automations. It can change how other people receive files or information about activity. Its administrative scope and directory visibility therefore need to be considered separately from a grant intended only for file operations. The permission options reference gives the complete set of permissions and the capabilities each includes.

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.

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.

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.

Folder Permissions