Folder Permissions

Folder permissions control who can access folders within your site. You grant them to users, groups, or partners.

For straightforward shared file access, start with users, groups, and folder permissions in the Default Workspace. Add Workspaces to group the resources and flows for a task or functional area, or to delegate administration; see Solution Design. Each Workspace still uses folder permissions to control access within it.

For non-partner access, user and group permissions layer together. The result for a user is the union of those permissions.

Permission changes apply to impacted users as soon as you save them. Adding a folder permission to an existing group propagates to every member of that group automatically. Removing a grant ends the access supplied by that grant; other direct, Group, or inherited grants can still provide access. It does not end the Share Links they already created or the email notifications created for them.

When Workspaces are in use, folder permissions are scoped to the Workspace. Workspace Administrators assign folder permissions to users, groups, and partners within their Workspace. Site Administrators can assign folder permissions within any Workspace.

To check a specific user's, group's, or partner's effective access to a folder and see where it comes from, use the Check Access feature from that folder's Permissions tab.

Allow-Only Permissions

Negative permissions, also called "negative ACLs", are explicit "deny" rules. Some systems use them to override inherited "allow" rules.

Files.com uses allow-only permissions. Users (except site administrators) and groups start with no access, and only the permissions that have been explicitly granted apply. This model keeps access decisions auditable and predictable.

Some directory systems support negative permissions. Files.com cannot synchronize "deny" rules from those systems, because there is no equivalent construct on the Files.com side.

During migrations, you can use permission fences to block inherited allow permissions at a folder boundary. A permission fence is not an explicit "deny" rule and is not a general replacement for negative ACLs.

Permission Options

Site Administrators can assign users or groups the following permissions:

Admin permission on a Custom Workspace's root folder gives a Default Workspace user or Group Workspace Administrator access, including administration of that Workspace's users and integrations. Admin permission on a subfolder remains Folder Admin access. Workspace Access and Administration explains this distinction and Group assignment.

Replacing Existing Files

Write and Read/Write permission let users create new files without giving them general permission to change files already stored in the folder. Replacing an existing file requires Full permission on its folder, except within the 15-minute allowances below.

This rule applies however the file is replaced: by an upload, a copy or move, or a file action that writes a result, such as Zip, Unzip, GPG Encrypt, GPG Decrypt, or document or image conversion.

Upload Replacement With Write Permission

Some transfer clients, including SFTP clients, upload part of a file and then resume at an offset. Requiring Full permission for that subsequent write would leave users who only have Write or Read/Write permission with incomplete uploads.

The following 15-minute allowances let those clients finish a transfer without granting the user general overwrite access. A follow-up write can be a continuation of an incomplete upload or a replacement of a completed file; the allowance permits both.

For 15 minutes after a user's upload to a path completes, that user can upload to the same path again to replace or append to whatever file is there. Each completed upload restarts the 15-minute window. The allowance applies across sessions, clients, and API keys belonging to that user, as long as the user still has Write permission on the destination folder. On a Remote Server mount, the allowance starts when the upload starts.

The allowance belongs to the user and the path. Deleting the file or replacing it with another user's file does not clear the allowance. Renaming or moving the file does not transfer the allowance to its new path. For example, if a Write user uploads to incoming/report.csv and a Full user then replaces that file, the Write user can still replace the Full user's file at incoming/report.csv within the remaining window, even after logging out and back in.

Separately, any user with Write permission can upload over an empty file that was created or modified within the last 15 minutes, regardless of who created it. This lets a transfer proceed when an earlier operation created the file without any contents. A Write user without Full permission receives a Full-permission-required error when neither allowance applies.

Custom metadata has its own allowance so uploaders can attach information to the files they deliver without needing Full permission. A user with Write permission can add or modify custom metadata on a file they created, for 15 minutes after that file was last modified. This allowance belongs to the file and its creator.

Archive Only Mode takes precedence over these permissions and upload replacement allowances. It prevents overwriting stored files. Only the uploading user can set or change a file's custom metadata, priority color, or client-supplied modification time, within 15 minutes of upload. Full or Admin permission does not let another user change those attributes or extend the window; Site Administrators follow the same rule.

When Broader Permissions Replace Existing Permissions

When you grant a permission that includes an existing permission for the same user, group, or Partner, Files.com keeps the broader grant and removes the redundant narrower grants it covers. For example, granting Full permission on a folder replaces that user's existing Read and Write permissions on the same folder. Granting Folder Admin permission on a parent folder replaces that user's direct permissions on the subfolders it covers. This does not reduce access: the new grant includes the permissions that were removed. Files.com stores only grants that add access instead of retaining narrower grants that provide no additional access.

Permissions are consolidated only when both grants belong to the same user, group, or Partner and the new grant actually covers the old one. A permission granted directly to a user does not replace permissions the user receives through groups. A permission granted to a group affects only other permissions for that same group. A permission limited to the selected folder does not replace permissions on its subfolders, and a Permission Fence prevents a permission above the fence from replacing permissions below it.

The narrower permissions are removed, not hidden. If you later remove the broader permission, Files.com does not restore them. Grant the narrower permissions again if they are still needed.

The Settings Changes log and History Logs record the new broader permission. The automatic removal of the redundant permissions is part of that grant, so it does not create a separate permission-removal entry for each permission that was replaced. When reviewing an access change, use the broader permission grant to identify why the narrower entries disappeared.

Path Matching on Remote Server Mounts

Folder permissions use Files.com's case-insensitive and accent-insensitive path comparison on both native storage and Remote Server Mounts. If a remote system stores archive/reports and archive/REPORTS as separate folders, a permission granted on either path applies to both. When the permission includes subfolders, it includes the contents of both folder trees.

To give the folders different permissions, use names that Files.com compares differently, such as reports-finance and reports-sales. Changing only capitalization, accents, or other Unicode characters that compare equally does not separate their access. Case Sensitivity explains the matching rule and how it also applies to API key path restrictions.

Permission List Visibility

Site Administrators can see every folder permission on the site. Folder Admins can see every permission on the folders they administer and all subfolders, including grants to other users, groups, and Partners. Ancestor grants, including site-root grants, are visible only when they are recursive and apply to a folder the Folder Admin administers. Non-recursive ancestor grants and grants that do not reach an administered folder are not included through ancestor visibility. Each record identifies the folder path, who receives the permission, its level, and whether it applies to subfolders. This visibility lets Folder Admins review direct and inherited access affecting their folders.

For example, a Folder Admin for clients/acme can see permission records on clients/acme and its subfolders. A grant on clients or the site root is also visible if it recurses into clients/acme; a grant limited to clients itself is not. That permission alone does not expose grants on clients/other or an unrelated folder such as finance. Additional Folder Admin grants expand the set of folders whose permission records the administrator can see.

The REST API permission list and the web app follow the same recursion requirement for ancestor visibility. The web app's Permissions tab focuses on the selected folder and shows applicable ancestor grants under Inherited. Check Access shows the effective access after inheritance and permission fences are considered.

Viewing a permission record does not give the Folder Admin that permission or authority to change it. An ancestor grant remains controlled by administrators of that ancestor folder; the Folder Admin's access to its files still depends on their own permissions.

Online Editors and File Previews

For editing documents in the Files.com editor and Microsoft Office for web, users must have Full permissions on the folder containing the file. Without Full permissions, users can open but not edit the document.

To preview files in the Files.com web interface, users need at least List/Preview permission. Read permission also allows normal downloads. List/Preview permits viewing content and is not a security boundary that prevents a recipient from capturing it.

Removing the permissions needed to edit a file prevents further saves under that user's identity, even if the editor remains open. An open editor does not preserve permission to write back to Files.com.

In a co-authoring session, the editor saves the combined document using the first participant's identity. Removing another participant's permissions therefore does not prevent the shared document from being saved while the first participant retains the required access.

Content already loaded into an editor or preview can remain visible after permission is removed, just as a downloaded copy can remain on a user's device. Revoking access controls further access to Files.com; it does not erase information already delivered.

Moving a Folder with Granted Permissions

When a folder is moved or renamed on Files.com, permissions assigned to it or its subfolders and its Folder Settings follow it to the new location. On Files Native Storage, the paths of the contents and their associated permissions update in the background, even after the move reports completed. While an item remains at its previous path, access is checked against the permissions for that path.

Moving or renaming a folder is not a way to end a user's access. Remove the permissions that grant access, including any applicable group or inherited permissions. Use Check Access to identify those grants.

For Remote Mounts, folder moves initiated from the remote server are not reflected in Files.com.

Deleting a Folder With Granted Permissions

Deleting a folder removes the permissions granted on that folder and on every folder inside it, including grants to users, partners, and groups. Creating a new folder at the same path does not bring those permissions back. An administrator can recover eligible user and group permissions with an in-place folder restore.

If the deleted folder was a user's FTP root folder, the folder is automatically recreated when the user next logs in, but the user has no assigned rights for the folder.

Share Links After a Permission Is Removed

Removing every grant that gives a user access to a folder ends that user's own access to it. Use Check Access to account for direct, Group, and inherited grants. This does not end the Share Links that user already created over the folder. Those links keep working, and a live link keeps showing the folder's current contents, because a Share Link belongs to your business rather than to the access of the person who created it.

To end a link, revoke it or set an expiration date. To put someone else in charge of it, change its owner. The Ownership and Sharing Policy page explains the behavior in full, including the site setting for organizations that want links to end when a user is disabled or deleted.

Email Notifications After a Permission Is Removed

Removing a user's permission on a folder does not delete or disable email notifications the user created or that an administrator created for them. The notifications continue sending activity emails even though the user can no longer access the folder or manage the notification. This applies whether the permission was assigned directly or through a group.

To stop the emails, a Site Administrator or Folder Admin for the folder must delete the notification. The user can unsubscribe from the link in a notification email. The Email Notifications page explains the behavior in full.